j-gray
-
Posts
620 -
Joined
-
Last visited
-
Days Won
5
Posts posted by j-gray
-
-
I've tried a number of agent-based tasks (clone reset, deploy agent, upgrade agent, etc.) and all simply time out. Based on the logs on the clients, the task is not even hitting them.
Is there nothing logged on the server-side that would indicate the issue?
-
The ra-upgrade* file does not exist on the system(s). Nor does the msiexec log. Windows Event Viewer shows no attempts to stop the Remote Agent service. Diagnostic logging is not enabled.
I also verified the the agent has not been upgraded and is still the previous version.
The task is timing out after exactly one hour.
I cleared out the Windows\Temp directory entirely and restarted the task. It is not generating any files there at all --I'd expect the agent msi file plus msi logs.
It appears the task is not starting at all on the client.
-
Thanks for the reply.
It appears the task is starting on ERA server. Client task shows Starting and Starting Task, but no info in the client's trace log and no msi log. It appears that task just isn't received by the clients.
I've verified the clients' info; correct name, IP address, previous agent version. They show in the ERA console properly, etc. and have good connectivity. status.html shows all good information and no errors in the trace.log files.
Anything specific I can check on the server to tell why the commands/tasks are not received?
-
I have a an upgrade task for the agent created that seems to be failing more frequently lately. The ERA console only indicates that the task is timing out on multiple workstations. I'm not finding much info to troubleshoot this.
Which specific logs would best indicate the issue and where are they located?
-
Agent upgrade is failing using the Remote Administrator Component Upgrade task on a few clients.
What does this error from the trace.log file mean:
Error: CSystemConnectorModule [Thread 8bc]: UpgradeInfrastructure: Task failed: File already exists 'C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Data\agent_upgrade_memo.json'. Cannot continue with agent upgrade
When I look in that location, the json file is not present.
This is on Win7-x64 clients.
-
Maybe a question, why you want explicitly the version 6.3, respectively what is preventing you from installing the 6.4?
Thanks for your reply.
The reason we want version 6.3 right now is this; we have 1600 clients (Win7 and OS X). Due to our larger and varied environment, we like to wait a bit before jumping to the latest release to ensure there aren't any major bugs that will cause issues. We also need to thoroughly test releases before we deploy them widely. Once we start to upgrade, we still go slowly to ensure we don't have any problems.
So at this point, I'm 25% through rolling out version 6.3 and all of a sudden it's no longer available. Which means I have to start the whole process over again for version 6.4...
-
I've been gradually upgrading our 6.2 clients to 6.3. However, now when creating install tasks, the 6.3 package is no longer available and has been replaced by 6.4.
How do I get 6.3 back in the list of available install packages?
-
I found a workstation (call it y) in the console with the MAC address of the client that's not communicating (call it z). The one in the console (y) shows offline, which it is.
So how do I fix this? Delete the one in the console?
-
Thanks for the reply.
The systems do appear in the console, due to AD sync. However, they show unmanaged/no status.
It's looking like an image was created with the agent installed and deployed without a cloned-agent-reset.
Given the systems think they're unmanaged, we can't run any tasks on them. Is there any way to reset the guid or other options to fix this with remote tools?
-
In the process of upgrading agents and find systems that appear to be unmanaged, so I deploy the agent. The agent deploys successfully, but the client(s) still don't appear as managed.
I look at the clients and they all have the agent + AV already installed. On each client, 'last-error.html' and 'status.html' are all good --no errors and replication is occurring successfully. No errors in the trace log, either.
We don't include the agent on images so there should be no duplicate guids, but is there a way to verify or potentially find duplicates?
Any other suggestions to try? Everything looks good on the client side....
Thanks much.
-
The 'Rename Computers' task runs every hour. In addition, because one of the conflicting clients was thought to be offline by ERA, it would delete it via the 'Delete not connecting computer' task. Then AD sync would pull it back into ERA when that task ran.
To work around the problem I:
- deleted both systems from ERA, then ran AD sync again -no luck
- deleted both systems from ERA, re-installed agent, then ran sync again -no luck
Only solution was to delete both clients from ERA, uninstall agent on both systems, then reinstall agent.
The hostname should not be changing at all on the network, except in a very rare case if a computer falls off the domain.
Unfortunately, this isn't an isolated incident, so I'm hoping to find the root cause...
-
I've attached a screen-cap that highlights the issue. Notice the hostname at the top, then the computer name at the bottom. Both of these systems have the agent and client installed but due to the hostname/IP conflict, they reflect various 'unknown' statuses. Yet both show green/current replications on their status.html pages.
All workstations are populated in ERA console via AD sync. None are manually added. Agents are all installed using the remote installation task. No GPO or other methods are used. We don't put the agent on images, so no cloning at all. One system shows some information in the console (see screen-cap). The other system named at the bottom shows up as unmanaged with no info.
And again, I've verified that DNS (both forward and reverse) are accurate.
Very puzzling.
-
The computers are appearing in the console with their FQDN. But the computer that is offline is reporting an IP address that a new/online client has been assigned.
This conflict in the ERA console is my best guess as to why the online/healthy system shows up as unmanaged in the console.
As far as the client with the corrupt db, I was able to successfully remove the network agent via remote msiexec command. The challenge was finding the older agent installer left behind (C:\Windows\Temp) on an older client (ERA only contains latest agent, which wouldn't work for uninstall of older agent).
It would be awesome if there was a universal agent uninstaller that worked across multiple versions and could be run via command line.
-
Thanks for the info. I think I figured out what is happening, just can't tell what's causing it. We're running AD Sync. Here's the scenario:
PC1 comes online and pulls IP 1.2.3.4. PC1 goes offline, but stays in ERA console with IP 1.2.3.4
PC2 comes online and pulls IP 1.2.3.4 (because that IP is now available from DHCP).
ERA now thinks PC1 is online because of the IP address previously recorded for PC1.
So ERA shows PC1 online even though it is not, and shows PC2 as unmanaged even though it is managed.
I've verified DNS does not have duplicate hosts for the same IP.
We're not cloning/imaging workstations or using workstation VM's, so there should not be any duplicate uid's.
Any idea what's causing this?
-
Only one system exhibits the corrupt database issue. The others have the HIPS error. Those with the HIPS error show they are replicating successfully with the server, but they simply won't show up as managed.
Is it safe to assume that the 6.2.190.0 agent is not fully compatible with the 6.1.2227.0 client?
And I'm still trying to figure out a way to repair these clients remotely via ERA console. Any recommendations?
Thanks again for your help.
-
On the system with the DB error, there is sufficient disk space. This one is running client 6.1.2227.0 and agent 6.1.444.0
The other two with the HIPS errors are both running client 6.1.2227.0 and agent 6.2.190.0
The problem in all three cases is that I cannot manipulate the systems remotely because of the agent; uninstall task will not run, upgrade task will not run. Deploy Agent task runs successfully, but does not correct the issue(s).
Given that I can't physically access the workstations, what's the best approach for remote repair?
-
Thanks for the reply.
I looked at the status.html file, which gave me a chuckle; everything is green and 'OK', server and certificate are correct, etc. But all the info was generated in October of 2015.
The only other info I found was in the trace log in the same folder:
Error: Service [Thread 73c]: SQLiteException: sqlite3_prepare_v2 failure
Error: Application UnregisterCECallback: failed with 7013The other two workstations exhibiting similar behavior show the following error:Error: CEssConnectorModule [Thread 984]: HIPS: Installed version of EES or HIPS is unsupported (Code: 14)
Any suggestions on best approach to resolve these, and what may have caused the issues in the first place?
Thanks again.
-
Agent installs successfully on a handful of Windows 7 workstations. I can see the services are running on each client. However, after hours/days, the client still shows in the console (via AD sync) as unmanaged/unknown.
I've had ESET running for close to a year now, and agent installs and policies are generally working properly, so these appear to be outliers.
How can I troubleshoot the issue remotely? I can access directories, services, etc. remotely, but cannot log on directly to launch any local gui's, etc.
Any suggestions appreciated.
-
IIRC, the earlier versions did not have this functionality and OU's had to be manually deleted.
Newer versions (at least 6.2 and up) have the option under the configured Server Task (Static Group Synchronization): Settings > Group Extinction Handling > Remove
-
Hello,
I'm running an agent upgrade (Windows) via ERA. On the client, I get the following error:
Error 1921: ...EraAgentSvc could not be stopped. Verify that you have sufficient privileges to stop system services.
I'm assuming there must be a policy option in ERA that blocks tampering with ESET services, but can't find anything in the console.
Any help appreciated.
-
Thanks. I found this KB article. I missed the fact that the Apache cache config required multiple manual commands to completely configure.
So I created the recommended scheduled task and ran it. Cache size is down to 2GBs. Much better.
...and just a heads-up; there are multiple syntax errors in the commands provided in that KB. I'm sure it would alleviate some frustration if it were corrected.
-
Thanks for the reply. I'm not sure what you mean by, "contents of cache htcacheclean". Is that a folder or file? If so, where it it located?
-
On Windows server, the Apache cache (C:\ProgramData\Apache HTTP Proxy\cache) folder seems to be growing excessively.
Currently, it's about 12GB in size and close to 1,500 folders. Is there a means or method to safely clean up this folder and reduce the size?
Thank you.
-
Btw, why are you not using Client Tasks instead? ERA agent is able to trigger both scan and update.
So I set up the signature update via 'Client Tasks', as you suggested. I can see by the logs that it is running on the clients (every hour, as scheduled). However, the Critical error persists; 'No regular updates scheduled' on all of the clients.
That being the case, I'm not sure what the best practice is for scheduling updates and scans for multiple OS's?
Task timeouts
in ESET PROTECT On-prem (Remote Management)
Posted
Yes, agent is definitely connecting, as it's running other tasks, (definitions updates) and reporting last connected time. Plus it's pulling proper system info, such as the application versions (so I know the agent needs to be upgraded), hardware manufacture, etc.
The Export config task runs, but nothing else, apparently