Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 3 subscribers
  • Views 1630 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SEC - problem with sql clustered database

Julien LONGHI

Hello,

I have a Sophos Enterprise deployment with the SEC (v5.5.1) installed on a Win2016 server and the database is hosted on a Windows 2012R2 Server / SQL 2016 cluster. There are about 3000 devices protected by the solution.

All was fine until three weeks ago (24/11/2018 02:06am).

At this date, I can see in the logs that the SQL server rebooted for an unknown reason.


The server restarted a few minutes later.


The problem I have is that the database SOPHOS files (SOPHOS551, SOPHOSPATCH52,...) stay at the 24/11/2018 02:06am date.
It seems that nothing is written in the files since that event.

There are only 3 temp files that are up-to-date, and one of them is tempdb.mdb.

I see no errors when I launch the SEC but I have to restart the Update Manager service about twice a week because it is doing nothing (nothing in the logs, no attemp to retreive the update).

I checked a lot of SEC's logs and I can't see communication errors with the database. I see only errors during the reboot of the database server.

When I test the connection to the database with the tool : CheckDBConnection.exe -s <SQL Cluster Instance server name>\SOPHOS -t onfce, I see with the <c> that the communication is established, but it's not done with a TLS1.2 channel.TLS1.2 is compatible but not configured. But it was fine before the event.

I can't understand how the SEC is showing the devices, the status of all and nothing seems to be written into the database files.

Thanks for your assistance,

Julien.





This thread was automatically locked due to age.
Parents
  • 0

    Hello Julien,

    the timestamps on the database files normally don't reflect the last activity but no change since late November is somewhat strange.

    Is the endpoint data in the console current? For example if you check the tab Computer Details do you see Last message times later than November? If not, then might SUM's status might not get updated for the same reason.
    To check SUM's activity please see the SUMTrace log in %ProgramData%\Sophos\Update Manager\Logs\. Are all Sophos services running, did you restart the Sophos Management Service after the SQL reboot?

    Christian

       

Reply
  • 0

    Hello Julien,

    the timestamps on the database files normally don't reflect the last activity but no change since late November is somewhat strange.

    Is the endpoint data in the console current? For example if you check the tab Computer Details do you see Last message times later than November? If not, then might SUM's status might not get updated for the same reason.
    To check SUM's activity please see the SUMTrace log in %ProgramData%\Sophos\Update Manager\Logs\. Are all Sophos services running, did you restart the Sophos Management Service after the SQL reboot?

    Christian

       

Children
  • 0 in reply to QC

    Hello Christian,

    After many investigations, it seems that it is a normal behavior and there is no impact on the SEC activity.

    The services of the SQL Instance were restarded last Monday and the timestamp of the mdb files updated.

    I have no new SUM update issue since last Monday.

    But what is strange is that when it occured, no more logs in the SUM logs, absolutely nothing. And all Sophos services were up and running on the SEC server.

    Thanks,

    Julien.

Unfiltered HTML