Issue with ESMC Migration

[DougS 0]

I have one apparently serious issue and two small issues that I cannot seem to resolve in the aftermath of a migration of SMC from one server to another. These issues are as follows:

 * The new ESMC server is not being recognized as having ESMC installed and running even though I can connect to the ESMC services on it using my web browser and manage it. The ESMC icon is missing from the new server entry;
 * ESMC thinks the ESMC server is running File Security 7.1.12006 when it actually runs 7.1.12008;
 * ESMC thinks the same ESMC server is running Management Agent 7.0.577.0 when it is actually running 7.1.717.0.
 
These arose as part of the migration of ESMC from a Windows Server 2012 running SQL Server 2008R2 to a Windows Server 2019 running SQL Server 2017. I needed to migrate to a newer SQL server due to the fact ESMC 7.1.717 requires a SQL Server newer than SQL Server 2008R2. I followed the instructions for migrating to a different server (https://help.eset.com/esmc_install/70/en-US/migrated_database_different_ip.html). While I had thought that I was following instructions to the dot, I subsequently discovered that the new server was still connecting to the era_db on the old SQL server. Immediately I stopped SQL Server services on the old server, backed up era_db, restored era_db to the new server, and reinstalled ESMC on the new server taking care to ensure that it was connecting to the era_db on the new server. I checked the About dialog box to ensure that it was connected to era_db on the correct server. I fear though that there may have been some actions taken that are reflected in the db that has since then been overwritten by the era_db from the old server.

Ever since then I have discovered these three issues and no matter what I do I cannot resolve these.

Regarding the first issue, I am unsure as to what the best way is to have the new server recognized as running ESMC functions by the very same server. Do I need to reinstall it (is there a repair function within the installer routine?)

Second issue: I have reinstalled File Security on the new server but the change is not reflected in the ESMC. From the ESMC console, I have fired off a software install task to install File Security 7.1.12008 on the new ESMC server. The task is shown as been executed and has been this way for the past 22 hours. I believe this has to do with the first issue listed above.

Third issue: this one is similar to the second issue. I have sent off a software install task and it gets started but doesn't complete. Again, I believe it has to do with the missing status of ESMC services on the new server.

All of the other clients and two other servers running File Security connect just fine with the new ESMC server.
I have yet to decommission the old ESMC server-- I will do this step once the above issues have been resolved.

Please advise as to what I need to do to get this fixed.

Thanks!

~Doug

[MartinK 378]

I will provide you some details of what is going on and maybe you will be able to pinpoint what went wrong and possibly resolve it.

All details of ESMC Server in console as seen in "computers" screens are actually collected by ESMC Agent installed on the same machine as is ESMC Server, i.e. from ESMC's perspective, it is just another client, but with installed different product's.

During migration to new server as described in documentation, ESET Management Agent is not migrated, which means it has to be installed on new server manually, as part of migration phase. This will result in fact that this server will be considered as new "device" -> at this moment I would expect that there will be actually two "devices" reporting installed ESMC Server in your console. One representing old installation, possibly no longer connection and with obsolete data, as this AGENT is probably no longer running. And there should be also entry representing new installation, with current data. In case this is not true, it is crucial to diagnose why ESMC Agent installed on new server is not connection to newly installed ESMC Server. Once this is resolved, all of your issues will be probably resolved. I would start by checking status.html of AGENT on server where ESMC is installed (see troubleshooting documentation for more details).

Also when checking presence and status of newly installed ESMC Agent in console, please double check this AGENT is not reported with different/unexpected name and in different group.

[DougS 0]

I reinstalled ESET Management Agent on the new ESMC server. Here is a clip from the trace.log showing that the Agent service on the new ESMC server is trying to reach the old ESMC server!

2020-02-26 20:03:16 Information: CSystemConnectorModule [Thread 2c14]: StatusLog_NETWORK_IPWINSSERVERS_STATUS: "Rows":[]
2020-02-26 20:03:16 Information: CSystemConnectorModule [Thread 2c14]: Retrieving installed applications list
2020-02-26 20:03:16 Information: CAgentSecurityModule [Thread 103c]: Agent peer certificate with subject 'CN=Agent at *, OU=Operations Support, O=DawnSignPress, L=San Diego, S=CA, C=US' issued by 'CN=Server Certification Authority, OU=Operations Support, O=DawnSignPress, L=San Diego, S=CA, C=US' with serial number '01b0c557b161eb4991bdb92dea7f480ee301' is and will be valid in 30 days
2020-02-26 20:03:16 Information: CDataMinersModule [Thread 10f0]: CFunctionalityLogDataMiner: Postponing functionality log of type: StatusLog_FUNCTIONALITY_PROBLEMSDETAILS_STATUS
2020-02-26 20:03:16 Information: CDataMinersModule [Thread 10f0]: CFunctionalityLogDataMiner: Postponing functionality log of type: StatusLog_FUNCTIONALITY_PRODUCTS_STATUS
2020-02-26 20:03:16 Information: CDataMinersModule [Thread 10f0]: CFunctionalityLogDataMiner: Postponing functionality log of type: StatusLog_FUNCTIONALITY_COMPUTER_STATUS
2020-02-26 20:03:16 Information: AutomationModule [Thread 3b44]: SimpleSchedulerTriggerBase: Trigger [UUID=00000000-0000-0000-7006-000000000001, TYPE=REPLICATION] registering scheduler event [StartTime { year: 2020 month: 2 day: 26 hour: 20 minute: 3 second: 15 } TimeSpecification: "R R/1 * * * ? *" UTCLocal: true].
2020-02-26 20:03:16 Information: SchedulerModule [Thread 4100]: Received message: RegisterTimeEvent
2020-02-26 20:03:32 Error: CReplicationModule [Thread 351c]: InitializeConnection: Initiating replication connection to 'host: "TAURUS.example.com" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "TAURUS.example.com" port: 2222 with proxy set as: Proxy: Connection: squid.example.com:3128, Credentials: Name: , Password: ******, Enabled:1, EnabledFallback:1, failed with error code: 14, error message: Connect Failed, and error details: 
2020-02-26 20:03:32 Warning: CReplicationModule [Thread 351c]: InitializeConnection: Not possible to establish any connection (Attempts: 1)
2020-02-26 20:03:37 Error: CReplicationModule [Thread 351c]: SendRequestAndHandleResponse: Rpc message response AUTHENTICATION_FAILURE (Token status: TOKEN_INVALID) -> Request new session token and resend replication request
2020-02-26 20:03:37 Warning: CReplicationModule [Thread 351c]: GetAuthenticationSessionToken: Received failure status response: TEMPORARILY_UNAVAILABLE (Error description: session token temporarily unavailable, device is not enrolled yet)
2020-02-26 20:04:50 Error: CReplicationModule [Thread 351c]: InitializeConnection: Initiating replication connection to 'host: "TAURUS.example.com" port: 2222' failed with: Request: Era.Common.Services.Replication.CheckReplicationConsistencyRequest on connection: host: "TAURUS.example.com" port: 2222 with proxy set as: Proxy: Connection: squid.example.com:3128, Credentials: Name: , Password: ******, Enabled:1, EnabledFallback:1, failed with error code: 14, error message: Connect Failed, and error details: 
2020-02-26 20:04:50 Warning: CReplicationModule [Thread 351c]: InitializeConnection: Not possible to establish any connection (Attempts: 1)
2020-02-26 20:04:50 Warning: CEssConnectorModule [Thread 477c]: Set policy request to product was successfull

How do I instruct the agent service to contact the new ESMC server? I tried applying the Management Agent policy onto the new ESMC server but it doesn't seem to take effect.

~Doug

[DougS 0]

One more thing.

The status.log indicates that the configuration is as follows:

    Use of HTTP proxy for ESET services is disabled
    HTTP proxy used for replication: squid.example.com:3128
    Repository hostname is: AUTOSELECT
    Update server is set to: AUTOSELECT with "delayed" update type

I'm assuming that the agent is looking for the old ESMC server under the present scenario as it hasn't been decommissioned yet. How do I make it point to the new ESMC server (i.e. itself)?

~Doug

[MartinK 378]

Just checked migration steps you followed and it seems to be missing one detail -> what happens is that installers you create in new ESMC are by default configured in a way that AGENTs will be connecting to old hostname.

As an workaround, each wizard for creating new installer offers possibility to override default hostname by your new. Solution in this case would be to modify/create new AGENT installer where new hostname is explicitly set in form that will look like this:

and AGENT should be re-paired by execution of new installer.

Another alternative is to run AGENT installer manually, where during installation phase you will be asked to specify hostname of ESMC server.

 

For long-term solution, most probably minor change will be required in database.

[DougS 0]

Ah! The management agent policy that points clients to the new ESMC server finally got applied to the new ESMC server and the agent is communicating with the server! It showed up as a new and separate entry in the list of computers. So i deleted the older entry (after following steps to stop managing, et al).

Reflecting on this, I realized that when I reinstalled ESMC on the new server, it probably reset the management policy to point to the older server (recall the use of AUTOSELECT?). So it was trying to connect with the old server all along. Lesson learned.

Onward to decommissioning the old ESMC server!

~Doug