j-gray

It can be either. Typically we only want to run certain tasks on workstations that meet specific criteria. A staged upgrade, for example. The task trigger may be manual, on group join, or on a cron schedule. We frequently use both of the latter two triggers on a group to catch already joined systems that are offline.

@Dannis Germain I have similar issues with notifications from Inspect. I wanted to get notifications specific to a certain static group only (under Monitored Static Groups), but email notifications would not send at all when a static group was selected. Support explained that the Group option does not actually work because there may be computers in different groups that get put into the same incident. I'm really not sure why it's presented as an option if it doesn't work. I'm guessing the case may be similar with your notifications, as an incident email could pertain to multiple workstations in multiple groups so it's just not reported. Additionally, I was not getting useful incident information in the alert subject, so had no idea what the incident actually was. The explanation for that issue was, "As far as the inconsistencies in the notification email, this is going to be due to the incident creator sending out what information it has at that time. New notifications are not sent out as the Incident is updated in Inspect." I gather they're still working on this functionality, so hopefully it will get better in the future.

Unfortunately, it is quite the opposite. I have a dynamic group that is supposed to contain only clients with the latest agent (criteria "agent = 11.4.1107.0") and it's full of clients with earlier versions. To add to the confusion there is no way to sort by or even display the agent version so I have no idea which clients are in fact running the latest agent. This makes it so we can't run tasks on these groups because the clients present aren't meeting the defined criteria to run those tasks.

I should clarify that in the past, dynamic groups would update if/when criteria are not met.

@Marcos It is working differently than it has in the past. Groups used to update immediately based on the criteria provided regardless if systems were online or offline. As it is now, for example, I updated the Latest Agent dynamic group using criteria of "agent = 11.4.1107.0". Currently there are only offline systems (141 in total), in this dynamic group, none of which have the 11.4.1107.0 agent installed. The dynamic group should be entirely empty, as we have no 11.4.1107.0 agents installed yet.

Just discovered after the recent cloud upgrade. My dynamic groups are only updating if/when systems are online. With the recent release of a new agent, I've updated dynamic templates and dynamic groups as I've always done to stage the upgrades. I have an Agent Upgrade group (agent not equal 11.4.1107.0) and a Latest Agent group (agent = 11.4.1107.0) for both Windows and macOS. In the past when I've updated these, the Latest Agent dynamic group immediately empties entirely as nothing meets the criteria yet. Now, the dynamic group slowly empties as clients check in. If they're offline, they do not get removed from the group even though they don't meet the criteria. Same case for the Agent Upgrade group; clients are slowly moving into that group as they check in, but if offline they are not landing in the correct dynamic group. This is the case for both Windows and macOS clients. In short, dynamic groups are not affecting offline clients.

No idea how I might discern that. Those systems are all on the same /24 subnet. They are not multi-homed and have a standard, basic network config via DHCP.

Yes, this opens TCP port 3389 again on those two devices. I'm still confused as to why this was impacting only 2 of 12 devices on the same subnet.

Thanks for this info. What's very puzzling to me is that we have at least 15 other Win11 workstations on that same subnet, all with the same ESET policies and same GPO's. ESET is blocking RDP only only two of those systems. All others show the TCP 3389 available/open. Netstat shows they're listening on that port, but it's otherwise blocked as soon as we install ESET. I can't figure out what's causing the inconsistencies.

The same EEA policies are applied to all Windows 11 workstations, all are running EEA 11.1.x. In this case, all are on the same subnet. We have a select few where once EEA is installed, TCP port 3389 gets closed. Port scan with no EEA shows 3389 open and we can successfully RDP. As soon as EEA is installed, the port is no longer available and we cannot RDP. Every other Windows 11 workstation except for two on the same subnet, same 11.1.x version and same policies, port 3389 is accessible. I can't tell how/why EEA is closing the port. Firewall is disabled, but IDS is enabled to allow Network Isolation functionality. Current policy is below:

Thanks, this is a good resource to have. For Support staff, as well. I was told that 1) there was no scheduled maintenance, and 2) the version 2.3 upgrade was on-prem and not cloud. We were down for close to 10 hours during regular business hours. This is not very ideal for something as critical as EDR.

@Marcos The case was #00812230.

I just created a support case as we're going on 5 hours now. Support assured me that no maintenance was scheduled, so should not be down for maintenance. So we'll see...

Ours went down around 09:00 MDT, so going on 4 hours now.

Getting this message for about 3 hours now and haven't been able to access our instance. It would be helpful if these upgrades could take place outside of normal business hours. It would also be super helpful to get an email notification when upgrades are going to happen so that we can anticipate and plan for the outage.