Jump to content

SkriptAsylum

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by SkriptAsylum

  1. Attached is eventually what I ended up doing (per recommendation from ESET Support).
  2. Per the title, what is the correct setting to make this happen? I'm looking to make it available to those in the 'Reviewer' Permission Set (which I understand is default of Read-Only) with a tweak or two to an individual parameter.
  3. Per other users, I second this feature request: Description: Agent installer that installs the latest [product] version by default. A checkbox for 'Latest Available Version' would be outstanding. Regarding the EULA/legal issues, perhaps another acknowledgement checkbox could justify the demand. Additionally, having no expiration for these Client Tasks would aid in the efficiency of the process [we currently have Dynamic Groups for 'ESET Not Installed' that trigger the Client Task to install Version 6.X that will fail if that repository has been removed].
  4. Let’s set the scene: A client is migrating to a new server soon, and the ESET Remote Administration Server/Console needs to be migrated as well. The new server is all prepped and onsite and you’ve been tasked to migrate the console and all X amount of client machines to this new server. This is a method I came up with to do this behind the scenes and without the need of client interaction. This works for Version 5 only! Explanation: What my method does is create a policy on the old server for all of current clients to grab that tells it to use the new server for Remote Administration and Updates. The trick is to have the new server already configured and ready to receive the new clients. Follow these steps exactly and you’ll be ready to rock: While both the original and new servers are available, install ESET Remote Administration Server/Console on the new server. You’ll need the nod32.lic license file provided originally for the old server for this new setup. Personally, I dump everything into an ‘ESET’ share on the new server [eea_nt32_enu.msi, eea_nt64_enu.msi, era_console_nt32_enu.msi, era_server_nt32_enu.msi, nod32.lic] Download definition file updates on the new server [Tools > Server Options> ‘Updates’ tab] and configure your client policy [Tools > Policy Manager]. It won’t hurt to export an XML of the config from the old server and import it here on the new at this point. The two most important things to change are the Remote Administration and Updates server address to the new server [Windows Desktop > Kernel > Settings > Remote Administration > Primary Server Address and Windows Desktop > Kernel > Update > Profile > Update Server]. In the case of my client, this was exporting the Policy XML from OriginalServerHere, importing into NewServerHere, then editing this address to be ‘NewServerHere’ where it once had ‘OldServerHere’. After updates are fully downloaded and verified, go to the old server and into policy [Tools > Policy Manager]. On the right side, choose ‘Add New Policy’ > Name It Whatever [I named mine ‘ServerSwap’] > Set Parent to the Original > Choose ‘Copy Merged Policy Configuration From Policy’ and choose the Parent Policy. This essentially copies everything from the original while giving us the option to point the clients to this ‘ServerSwap’ policy, by… … Selecting all clients from the Clients tab > Right-click > ‘Set Policy’ > ‘Server Swap’ and ‘Set Policy’ to apply. All clients should now show ‘Requested Policy’ as ‘Server Swap’. The next time they call in [default of 10 minutes], this should show the change and the new clients will appear on the new server. After all machines have called in, it’s safe to delete the clients from the original server.
  5. ~Good Afternoon, I submitted this awhile back to ESET Support [just over the phone], hoping to have it become a Knowledge Base article. This is in regards to: https://support.eset.com/kb6067/ Either due to my lack of familiarity with PowerShell, or because of existing machine settings, I could not get the PowerShell portion to function [listed in Step 9]. I've crafted an alternative method that still enlists PowerShell but in a very different manner. I've had this work on all versions of Windows along with machines joined to the domain or simply on workgroups. Adjusting primarily Step 9: Download Task ============= Executable File: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe Work Folder: C:\ProgramData\ESET Parameters: bitsadmin /transfer ESET /priority high https://YourWebpageHere.com/ESETAgent.bat C:\ProgramData\ESET\ESETAgent.bat Run Task ======== Executable File: C:\ProgramData\ESET\ESETAgent.bat Work Folder: C:\ProgramData\ESET Parameters: [Blank] Using the above, this will request PowerShell to use bitsadmin [built-in tool for Windows computers] to download 'ESETAgent.bat' from a webpage host and place it in C:\ProgramData\ESET. Then, the Run Task will execute the batch file as-is. I have heard reports that this leaves a small 'gear' icon in the taskbar, but it can be closed/ignored. Regarding the Download Task, I didn't have much luck using Windows Shares, namely how to craft the parameter and what ESET would accept. Also, rather than creating a new Policy, I enjoy just modifying the Policy as-is and setting the connection interval to 1 minute as to alert me to which clients are active [Windows Desktop V5 > Kernel > Settings> Remote Administration> Interval Between Connections To Server]. I've had the most amount of success migrating clients to the Version 6 RA through this method and hopefully someone finds it useful. My 2¢
×
×
  • Create New...