j-gray
-
Posts
620 -
Joined
-
Last visited
-
Days Won
5
Posts posted by j-gray
-
-
I have Device Control disabled via ERA policy.
The client GUI (OS X) also shows that it is disabled. However, in the GUI under Tools > Log Files > Device Control there are a ton of Disk Storage 'allow' events. It appears to log two events every 11 minutes.
Why is Device Control interacting with the system at all if it's disabled? Is this a bug and/or is there a way to stop this entirely?
-
Hello j-gray,
we would like to reproduce it internally here, but I'm not sure about the exact steps ;-(
you stated, that only real-time protection is enabled, right? It does not help, so it has to be that particular feature. Would it be possible for you to send me an exported configuration from such machine? Or even better with the info_get script output as described here?: hxxp://support.eset.com/kb3404/can you please run it right after the issue occurred?
Later in the steps you mentioned you pushed an agent and the Endpoint itself, so it means that the Endpoint was installed before in an non-managed environment?
It there an protection, which disabling resolves the issue, or you have to uninstall the endpoint completely?
Thank you, P.R.
Yes, at this point, real-time protection is the only component enabled. Initially we had most components enabled (phishing, email and web) but in an effort to make the software function at all, we disabled those components. It's a little better, but still has major performance issues.
I tried to attach an exported config, but the file type is not permitted. I've also sent multiple logfiles to support from the info_get script. They should be attached to my support case.
Our process is generally as follows; install OS or push image, join to domain, install other software (MS-Office, Adobe, etc.), install agent manually using live installer. Once the system(s) appear in ERA, the AV is pushed out. Same policy is applied to all Macs using dynamic group (OS = OS X). We do not apply the agent to images. It is always installed manually after imaging.
I will try disabling real-time protection to see if that makes a difference. We've generally just uninstalled it completely, leaving only the agent.
-
What version of ESET Endpoint are you running?
We were initially running 6.2.7.0 with agent 6.3.110.0. I've moved a dozen or so to 6.3.85.0 with the latest agent, 6.4.232.0.
We've had to remove ESET from the rest.
-
Thanks for posting, Peter.
In our case (refer to my link above), it's strictly a startup issue and affects all OS X clients (we have 10.11.5 and 10.11.6).
The clients are joined to Active Directory via OS X native Directory Utility.
We've disabled all components, except real-time protection, and set those options to least impact.
Then; install the agent via ERA, then install the AV client via ERA.
On subsequent network/domain logins, the systems hang for 2-5 minutes until the ESET icon finally appears in the menu bar. After that, everything appears to function properly.
We have no unusual applications or configurations that should cause issues or conflict with AV.
-
Perhaps similar issues to this thread: https://forum.eset.com/topic/8696-eset-endpoint-security-for-mac-os-x-startup-issue/
At least for us, performance is OK once we get passed the delay at startup/logon. Are you in an Active Directory environment?
I would recommend disabling all but real-time protection, and setting it to the least restrictive settings. Then enable other pieces bit by bit to see what causes the most performance issues.
It will be slow and painful, but there appears to be little support from ESET for the Mac clients --my ticket is going on 2 months now with little response.
-
Hello j-gray,
What do you mean by "immediate policy refresh"? You mean, that when you have performed some changes in the policy, you want the agent to connect to ERA, and start using the new settings? As of now, a wake-up call is the way.
Exactly. Though I view wake-up call more like wake-on-lan, requiring network broadcast, which is not a good practice across multiple subnets.
I'm looking for a simple 'send policy' that doesn't require network broadcast. Even if it's a basic command I can run from the client (remotely).
-
Description: Mechanism to force policy refresh on client(s) from ERA console.
Detail: There doesn't appear to be a way (that I've found) to force a client to pull a new policy. We either have to wait for the policy refresh interval or create a new policy with a shorter refresh interval and apply it. It would be great to have a right-click option from the ERA console to force an immediate policy refresh.
-
Description: Better method for detecting unmanaged clients
Detail: RDS is not a practical solution in environments with multiple LANs, it can't be installed on OS X, and relies on outdated/unsupported software (WinPcap).
A simple ping-sweep tool that works across multiple subnets and shows unmanaged clients, or better yet, a dynamic group that does the same so that an agent install task can be run when client joins the group. This would be awesome, especially for OS X where Group Policy automated install is not an option.
-
As you can see, the build number is not changed, only the last suffix.
Yes, I understand this. However, because it is a new version, we're required to test it before we deploy it to the masses. This is common practice.
It also breaks the current deployment task because the specified package is no longer available, and it forces us to stop our current deployment, again, because the package we were deploying is no longer available.
-
I believe this was reported previously, there was a proposal to keep older versions in the repository to guard against this. I guess it hasn't happened yet.
Yes, I thought there was a previous thread, but I could not locate it.
There is a checkbox to select legacy software, but those packages are much older.
ESET: please allow customers to chose the version of software they wish to install.
This really causes issues when you take away software in the middle of a rollout.
We finally completed testing of 6.3.85 and now it appears to be no longer available.
-
What package version you were rolling out? It might happen that it was replaced, due to reported issues with the macOS sierra installation. Was it 6.3 already?
We were rolling out 6.3.85.0
It looks like it was replaced by 6.3.85.1
-
I've been rolling out OS X clients with a scheduled task on dynamic group.
All of a sudden, the task is failing with the error, "Package not found in repository".
I found that there is a newer version of the client and the version I've been rolling out is no longer available.
How can I get the previous package back so that I can finish our rollout?
-
Just to update you on the progress, we have created a bug report based on your reports. Just out of curiosity, have you contacted ESET support regarding this matter, so we can theoretically link it to any open support case? Thank you.
Thanks for the update.
I created a case a week ago (#1480064). They suggested the issue was caused by DNS reverse lookup (it is not). Otherwise, they suggested creating a Server Task to rename the clients to solve the issue. However, we already have this task running and it does not resolve the issue.
-
They've also rebooted multiple times, so the agent has been reset multiple times.
Actually rebooting will most probably won't help in case problem is with startup order. Not sure what "software" you are using to join domain on Mac OS X, but in case it starts later than AGENT, FQDN may be fetched before computer is actually joined into domain ... but that is only hypothesis.
Also it seems AGENT uses system calls that should be equivalent of output from scutil command line tool available from terminal. Could you please check output of these command on problematic client is possible?
scutil --get HostName scutil --get LocalHostName scutil --get ComputerName
so that we can check whether system is providing correct values to AGENT.
We add them to the domain with the Directory Utility, which is native/built in to OS X workstations. This should not affect the computer name at all.
I ran the commands on systems reporting in with correct FQDN and systems reporting in as computername.local and got the same results for all:
HostName: not set
actualcomputername
actualcomputername
In all cases, the systems are reporting the correct computer name, just not appending the correct domain suffix consistently.
-
Key question is whether this computer is actually in domain? What do you expect in FQDN
All workstations (Mac and Windows) are domain joined.
Domain suffix (search domains) and DNS servers are configured via DHCP server.
So workstation name is: ws-osx-01
Domain suffix is: contoso.com
FQDN should be reported as: ws-osx-01.contoso.com
All of these systems resolve in DNS (forward and reverse) with the proper FQDN. They've also rebooted multiple times, so the agent has been reset multiple times.
-
Could you please check what is Mac client reporting in it's client details view - in section "Device identifiers"?
In the Device Identifiers section, it reports the 'Computer name' correctly (name only). However, it reports the FQDN as computername.local
As zhopkins reported, it appears to be random whether they report their proper FQDN or just .local.
Also, I have a task to delete not connecting computers. I have another task to sync AD. So the first task removes the clients with FQDN because it thinks they're not connecting (when actually connecting as computer.local). Then the AD sync task brings those objects back into ERA because they exist in AD.
This would seem to be a bug or shortcoming with the product, no? Or is it working as designed?
-
Running the latest ERA Server and OS X agent. Active Directory environment, OS X devices are domain joined and DNS suffix is appended via DHCP option.
Many of the OS X devices show up as 'computername.local' instead of their fully qualified domain name (like Windows clients do).
Typing 'hostname' in terminal reports the workstation name with FQDN, so I'm not sure where the issue is.
This causes the system to appear twice in the ERA console; once as the .local and once as the FQDN (from AD sync). The AD sync'd version always shows offline and the .local as online.
I have the auto-renaming to FQDN task set to run hourly, but this does not resolve the issues.
Any ideas how to get the clients to show up with proper hostname including FQDN?
-
There is no way how to do that directly, you have at least two possibilities:
The dynamic group is "OS edition . OS type = (equal) Mac OS", so our OS X policies are applied to all OS X devices. This made the most sense to me as we want the same policies applied to all our OS X devices. So in this case, it's not possible to move OS X computers outside of that group's scope. Option 2 looks like the only viable option.
It would be awesome if there was a way to exclude policies or otherwise block policy inheritance in certain groups for testing purposes.
-
I have policies applied to a dynamic group (Mac Computers).
I have a static group called 'Test Group' for some Macs. I'd like to exclude the policies applied to the dynamic group and have only policies for the static group applied.
Is there any way to exclude policies?
-
I ran a scan with cleaning on an OS X system and the scan found numerous Potentially Unwanted Programs.
When I look at the client details under Threats and Quarantine all rows under the 'Resolved' column are blank, and all rows under the 'Action' column are blank. In some cases, there are no values in the 'Threat Type' column; some are flagged PUP, others Application, and some are just blank as if they're not categorized.
My biggest concern is that the scan completed, found and flagged the threats, and from appearances did nothing to mitigate the threats.
Any suggestions get this system clean?
-
Thanks for the info.
This is another one of these where status.html shows everything fine, trace.log shows no issues. Client is pointing to the proper IP for ERA server, but the workstation does not appear in the ERA console either by name or by IP address. It does not appear to be getting the latest policies, either, despite no errors.
-
Is there a way to do this from the client? And/or is it logged somewhere on the client?
I've visited a few OS X clients that don't seem to be getting the latest/correct policies. I'd like to be able to force the client to pull its policies and verify that task completed successfully or failed.
Is it possible to accomplish this?
-
Does this problem returns after service restart?
In all cases, clients are connecting to ERA server, updating connection info, reporting correctly, updating virus DBs, etc. Just not running any tasks sent from the ERA console.
In all cases, trying to stop the ERA agent results in the service hanging in a 'stopping' state. I then have to use pskill to terminate the service successfully. The service restarts on its own, but I've found I have to manually stop it and restart it again for any tasks to run. After killing the process it stops and starts manually without issues and I can rerun the upgrade task successfully.
I have a dynamic group set up to catch all Windows systems that have agent installed with version < 6.3, then have Remote Agent Upgrade Task run automatically on these. Some run fine, but many fail.
I will try to generate some minidump files.
-
So I've enabled full trace logging, but still nothing relevant is being logged. I can see the start module, applied policies info, but no errors.
From what I gather, the RA service is not working fully. These systems get updates, policies, etc. but won't run other tasks and don't even log those attempts. Restarting the service clears the issues and allows tasks to finally be run. This is impacting a number of workstations, and making things fairly unreliable, since necessary tasks won't run until a system is restarted or we manually intervene.
On another note, I really feel there needs to be better logging and it needs to be centralized. Individual workstations may be offline, out of the office, etc. and jumping from one client to another, scrolling through logs (that in my case had no useful info) is tedious and time consuming. The purpose of the ERA server is for central management, so it makes sense that one should be able to do relevant troubleshooting from a central location.
OS X clients report as name.local
in ESET PROTECT On-prem (Remote Management)
Posted
Could you please provide some more information on this?
I've been working with support, and so far they haven't indicated that this is a bug or a known issue. They're simply asking me to rename the hosts via command, which I don't feel is a solution.