ShaneDT
-
Posts
236 -
Joined
-
Last visited
-
Days Won
3
Posts posted by ShaneDT
-
-
Certificate contains list of hostnames/IP addresses that your SERVER can be accessed from AGENTs. In case your AGENTs will be able to reach new SERVER without configuration change (i.e. they will be connecting to exactly the same hostname) you can use the same certificate as now which enables you to use migration type Migrated Database - same IP address even if IP address will be different. There would be problem only in case clients are currently configured to connect to IP1 but new server will use different IP2 which is obviously not signed in SERVER's certificate.
OK so the certificate contains both the hostname and IP address of the current server. I tried to see if I could view the details of the certificate on my server last night but couldn't figure out how to do this. So as long as the hostname or the IP address is the same on the new server, the existing certificate will work fine?
Must admit certificates are not my strong point lol.
-
Thanks Martin, I'll stick with 6.3.136 for now.
So reading the above section of the install guide, the new server will have the same IP address, but the server name and Domain name will be different. I'm not too worried about migrating over the database, I assume once the clients start connecting to the new server they'll appear in Lost & Found first, I then run static group synchronisation and they'll be moved to their correct static groups based on active directory and will update the new server database with their details (just maybe not past virus/scan history?).
So the option I should choose is 4.3.2 Clean Installation - different IP address correct? (Same IP address option suggests server name etc must also be the same).
But being that I'm using the same IP address, will I need to create the new certificate?
Obviously I won't need to create a new agent policy for the new IP address.
-
Thanks Martin, no I didn't think to check the manual (embarrassed). I did do a google and quick search of the forum though
Anyway will have a read tonight
What are your thoughts on whether I should install the same version ERA 6.3.136 on the new server for starters, or just go straight to 6.4?
-
Scenario.
Small customer 15-20 clients with ageing SBS2008 server with ERA6.3.136 installed.
Replacing server with new server running Server 2012 R2 Essentials. Being built offsite.
New server will not be on the network at the same time as the old server due to some common parameters (inc IP address).
Will not be 'migrating' the servers (ie active directory), new server will be a clean build. Will migrate clients using Profwiz.
First question. Should I install 6.3.136 first on the new server, then once all clients moved across, upgrade to ERA 6.4?
What is the best/easiest method to migrate the clients to the new server?
I figure one option is to simply uninstall the agent on each client and reinstall the new agent once they are joined to the new AD.
Though I do have 8 notebooks that are rarely in the office and they connect back to the ERA server over the Internet.
Is there a write up anywhere on how to migrate the database from one server to another?
Can I install ERA6 with the existing licence while it is installed on the existing server?
Thanks
-
do you have the Apache Proxy enabled in the agent and client policies?
Yes, but according to Eset partner support, activation doesn't go through the Eset proxy or ERA server, the client connects direct with the Eset activation servers online. So unless I was running a network/Internet proxy (which I'm not), it should be a direct connection. Also the policies applied were the same on the server that did activate.
-
So in case of changes, you have to ship a new file manually with the new license information. Offline files are also restricted to offline environments, so when you have activated with offline file, you have to make sure, that the computer that was activated with offline file won´t reach edf.eset.com, as otherwise ELA would reject creation of further offline files due to violation (offline files, should be used as a last resort).
When I first created the offline licence file and activated the server, the server wouldn't update, so I had to log back into licence administrator and create a second offline licence file, this time selecting to include the username and password, then activated the server a second time with this new file, which then successfully updated. I then deleted the original offline licence file. I didn't have any problems doing this. ELA didn't reject creation of the offline licence file.
-
The main difference between the online and offline activation is, that in case of online, each activate computers reaches our activation servers, gets unique SeatID, which is then paired with the license, and license file with encrypted license information is delivered. Then, the application is configured to automatically receive any updates that might happen on the license (renewal / extension / cancellation / ...).
When using offline file, you do not create the seat ID instance, and you deliver the license file directly. So in case of changes, you have to ship a new file manually with the new license information. Offline files are also restricted to offline environments, so when you have activated with offline file, you have to make sure, that the computer that was activated with offline file won´t reach edf.eset.com, as otherwise ELA would reject creation of further offline files due to violation (offline files, should be used as a last resort).
Most of the times, failed activation attempts using online method are related to computer not being able to reach activation servers (edf.eset.com), communicating via proxy, or not having the latest Windows updates installed.
Hi Michael, so what you're saying is I am going to have problems with these servers activated with the offline licence files
I have ticked both the username/password and the 'Allow management with remote administrator' boxes when creating the offline files, and the licence information has updated in the ERA server console. Both these servers are actively connected to the Internet.
Also these licences are currently on 30 day trial, and will be converted to paid licences in a couple of weeks. So you're saying I will have to create a new offline licence file once the licence is converted?
In both cases no problems pinging any of the activation servers, no Internet proxy, and all MS updates installed.
-
You can simply create new policy (or edit existing), "apply" settings you want to be applied to all clients, for example add your IP to server list. Once configuration is ready, assign this policy to group "All". This will be settings applied in case there are no other policies overriding them.
Hi Martin, yes so in this instance that's what I've now done, but I've applied the new policy directly to each static group with LAN based computers.
But my question was, when you first setup an ERA server, there are no policies with the 'Servers to Connect To / Edit Server List' configured. Also when you create an EraAgentInstaller. bat file, again the server_hostname field is optional. If left blank it doesn't specify the ERA server to connect to. So with a default installation there is no server specified to connect to. Yet when you deploy the agent locally from the ERA server or via EraAgentInstaller.bat, the client Agent does connect to the ERA server.
I agree though it's a moot point as I've created the additional policy to reset this to the correct server address. Just trying to understand how this works.
-
Shouldn't these activation/connection failures be logged somewhere? You mentioned earlier using Wireshark. What exactly would I look for using Wireshark?
There has to be a reason why 2 out of 3 servers refused to activate. I have logged a partner support case and referenced this thread, so hopefully someone will come back with some ideas. For now it's activated though I don't know what issues activating using an offline licence file vs directly from the ERA server will cause?
-
I've had issues with activation before, but a couple of restarts has previously resolved the issue. Thankfully the other remote notebook I mentioned in my opening posts fell in this category, this notebook resides several hundred kilometres away and getting remote access to it is not easy. In this instance restarting the servers didn't seem to make any difference.
-
So just on this point, how can you remove a server setting from the Edit Servers List when you can't configure this policy without a server address?
I am not sure I understand your question - why would you want to have empty list of server to connect to? That would result in AGENT unable to connect to ERA server.
When applying list-based configuration parameter, there is nothing like merging/joining/subtracting lists -> if you have multiple policies assigned to AGENT with applied "Servers List", only one list will be applied from policy with higher priority (or based on "force").
Example: if you have two policies, one containing WAN ip in Servers list, and another policy containing only LAN ip, resulting configuration of AGENT will contain only one IP.
The default policy 'Remote Administrator Agent - HTTP Proxy Usage' does not have any servers listed in Edit Server List. The default policy only applies the ERA server as the Eset proxy server. So how do I return to this default state?
-
Again can't activate via ERA client task. Can't activate directly in EFS using the Licence Key. Only option that worked was an offline licence file.
-
Unfortunately I am not able to verify ESET server's functionality, but this seems to be connection problem. My last idea is to check whether all IP addresses from list of ESET EDF servers is accessible from this machine, as they may change request to request and also based on regional location.
I've just installed on a third and final server for this customer, again deployed from ERA, EFS installed but has failed to activate.
Of the list of hostnames and IP's listed under 'Services', the following did not respond to ping. But they also did not respond to ping on the server that did activate. They also did not respond to ping on my own computer which is on a completely different network/Internet connection.
edf.eset.com 137.135.12.16
edfpcs.trafficmanager.net 137.135.12.16
edf-pcs.cloudapp.net 137.135.12.16
edf-pcs2.cloudapp.net 137.117.215.70
91.228.165.73
212.73.202.110
-
I am asking, because there is one common misunderstanding: when you apply specific setting to client, and then remove policy that applied this setting, client will remain using value from last policy even if policy is no longer available or applied. Value will be changed only after any other or new policy applies mentioned setting. In your case it seems clients were in history configured to connect to WAN IP (maybe accidentally assigned policy?) and after policy was removed they remained using WAN IP until you crated new policy for LAN computers.
So just on this point, how can you remove a server setting from the Edit Servers List when you can't configure this policy without a server address?
So removing the policy won't remove the setting, but you can't apply a new policy that sets it to blank either?
It would be good to have a 'Refresh Policies' option that forces the client agent and installed software to reset all settings based on the currently applied policies in ERA.
-
Unfortunately I am not able to verify ESET server's functionality, but this seems to be connection problem. My last idea is to check whether all IP addresses from list of ESET EDF servers is accessible from this machine, as they may change request to request and also based on regional location.
Again as per my post in my other thread, what method should I use to test this. Is ping sufficient?
Please provide more comprehensive instructions. We don't all know your product as well as you know your product.
-
How do you "export configuration from affected clients"?
Martin please understand I don't work for Eset or spend all my time working with your product. I run a very busy business supporting over a dozen very active customers with probably hundreds of different products. I don't have time nor should I need to know your product as well as you do. I appreciate that you and others are responding to my posts but providing instructions on how to do something or links on where to find information would be very helpful. I've already lost half my weekend to unexplainable problems with your product. Do I really have to spend another hour researching how to do what you've suggested?
I'm sure there are partners on here that know a lot more than I do, I'm only very new to the world of Eset. But I'm sure there are many partners and customers that would appreciate not assuming we know the product or troubleshooting processes as you do.
-
No, in fact this policy was only created on Friday, all the PC's had been installed and configured a week earlier. So there is no way this policy ever applied to these PC's.
The agent for the servers was also installed over a week ago. Again no where at this point was the WAN IP configured. This was only configured and applied to a specific static group on Friday for remote notebooks. Somehow these settings made their way to all computers on the network.
I've also seen this on another customer network, also running the same version of ERA. This was my previous post about changing this for remote computers. For some reason their terminal server was trying to connect to the old WAN IP address, again even though this policy had never applied to this static group or server. At the time I put it down to the customer running the EraAgentInstaller that was meant for the notebooks on the server. Lucky I didn't call him out on it
-
So I managed to get the server activated and updating by creating and downloading a second Offline Licence File, this time selecting to include the username and password.
So I have a workaround that's working. Would be good to get the problem identified and resolved so I don't run into it again.
-
Never worked with IIS logs?
Not really no lol. Windows logs, application logs, firewall logs, never had any that were UTC. Just must have been lucky.
Anyway can we get this back on topic.
-
Log files are UTC. Most log files, on most systems, are UTC. Otherwise they're a nightmare to analyse when users are in different timezones and with daylight saving etc. Having log files in local time is daft.
Really, well every log file on every system I've installed and supported for over 15 years is in local time format. Maybe this is easier for Eset engineers. Not so much for everyone else who is not used to working in UTC.
-
And even though I have now activated this with the Offline File, every 9 minutes I'm getting the following email, I assume from the ERA server.
"During execution of Kernel on the computer SERVER, the following event occurred: Activation was not successful: Could not reach activation server."
-
Managed to activate it using an Offline Licence File.
But now it won't update. Getting error: Your license file does not contain a username and password. You can update only from an update mirror.
I guess everyone at Eset is asleep.
-
I have uninstalled EFS and the Agent, restarted, reinstalled the Agent, reinstall EFS, and still fails to activate!!
Looks like I'm going to have to reinstall McAfee! At least it works.
-
I also created a new policy adding the local ERA server IP address in the Edit Server List with the Force flag enabled, and assigned this to the local network PC's static group - still no change on the client!
Edit: Actually this did finally work. Took 2 'connects' from the client to ERA server to reset this. All the above issues still apply. At least now I have a workaround.
Online scanner crashes
in ESET Standalone Malware Removal Tools
Posted
Yep, this v2 online scanner is rubbish (sorry Eset). I've been using the Online Scanner with my customers for years, very reliable.
This latest v2 rarely ever finishes without crashing. Worse, when it crashes it leaves no record of what threats were detected and possibly deleted. And no quarantine to restore any false positives.
Please can we have v1 back again.