Update check failed, error=211 (server returned an error)

dizzycloud

Greetings!

I have the following issue:
When trying to request virus-signatures or other updates, both the clients protected by WithSecure Business Suite and the Hyper-V (Which currently runs With-Secure Server Security Premium) fail to request the updates.

I get the following logs in C:\ProgramData\F-Secure\Log\AUA

2023-10-24 10:37:01.874 [3f94.6558] I: Checking for updates from [PM-Proxy-Adress]/ws-guts2
2023-10-24 10:37:01.874 [3f94.6558] I: Update check failed, error=211 (server returned an error)


Does anyone know why this could be happening?

I checked the connections and the PM-Proxy is pingable.
I also used the internal tool wsconnectionchecker under C:\Program Files (x86)\F-Secure\Server Security\ui to check the connectivity to with-secure's servers.
They're all functional.

If anyone knows what Error=211 stands for, or if they have an idea how to resolve this issue, I'd appreciate the help.

With kind regards,
Roland

Sethu Laks

Hi @dizzycloud

Thank you for reaching out to the WithSecure Community.

Providing a precise solution for the reported error is challenging without analyzing the wsdiag logs. The error you've described, which is "Update check failed, error=211 (server returned an error)," can stem from various causes. We recommend that you follow this checklist step by step to determine if it resolves the issue.

1. Ensure that all required SSL certificates are present. Once these certificates are in place, the issue should be resolved.
2. Check if Windows updates are disabled. Make sure Windows updates are enabled and installed. If the problem persists even after Windows updates are installed, consider the following workarounds:
   1. Manually install the Digicert root certificate authority from https://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt . WithSecure uses the Digicert root certificate authority.
   2. If you are using a third-party Certification Authority (e.g., Starfield, GlobalSign), ensure that these certificates are valid and correctly installed on the host.
   3. Try adding the certificate to the user's profile if the "local machine (all users)" option does not resolve the issue.
   4. Test by switching to Google DNS (8.8.8.8 and 8.8.4.4) to see if DNS may be the underlying issue. You can check this by using ping to guts2.sp.f-secure.com, and if it fails, switch to Google DNS.
3. In the case of Servers Security, the installation might encounter issues if you have enabled the "Turn off Automatic Root Certificate Update" option and don't have the latest root certificates. To resolve this:
   1. Enable automatic root certificate updates via Group Policy: Navigate to Computer Configuration / Administrative Templates / System / Internet Communication Management / Internet Communication Settings / Disable Update automatic root certificates. Ensure that it's set to "Not Configured" or "Disabled." This setting should not begin with "Turn off" since enabling it prevents Windows from downloading necessary new root certificates.
4. If none of these above measures do not resolve the issue, you can reach our WithSecure Support for further investigation.

Best regards,
Sethu
Community Moderator | Technical Support Engineer
WithSecure™ https://www.withsecure.com/en/home

dizzycloud

Greetings!

Thank you for your help.

I have tested the DNS issue, guts2.sp.f-secure.com is pingable.
I also reinstalled the Certificates, but that did not resolve the problem.

As far as the Windows-Updates are concerned, the infrastructure isn't exactly the newest environment. I will have to ensure that all Backups are functional and that I can restore the environment once I turn off the Hyper-V.
I will need to wait for the next maintenance-window before I can ensure that the Hyper-V is up-to-date.

Once that is done, I will return with new information (and hopefully have that issue resolved).
Thank you for your help, much appreciated.

With kind regards,
Roland

Sethu Laks

Hi @dizzycloud

Thank you for keeping us informed. If the issue persists, we would recommend generating the wsdiag (formerly fsdiag) from the affected client machine and contacting our WithSecure Support team for a more in-depth investigation.

Best regards,
Sethu
Community Moderator | Technical Support Engineer
WithSecure™  https://www.withsecure.com/en/home

Soboknilch

Hello,
I have the same problem since upgrading to version 16.01.
The clients can no longer connect to the Policy Server...

The server call has also changed...

from: server.domain:8084/guts2
to: server.domain:8084/ws-guts2

does something have to be adjusted somewhere ?

Sethu Laks

Hi @Soboknilch

We recommend you to check and update the PMS address and lock the following setting on the highest domain level under the policy domain tree in the existing Policy Manager Console 16.x, and then click on the "Force value..." button to push the value to the lower level domain/host level:

• Settings(Standard view) > Centralized management > Policy Manager Server address
• Settings(Standard view) > Centralized management > HTTPS port
• Settings(Standard view) > Centralized management > HTTP port

Distribute the policy after this.

Other than this, you need to ensure that the admin key pairs(admin.pub and admin.prv) used on both the existing and new Policy Manager Server are the same. If not, the clients are unable to communicate with the new Policy Manager Server in this case.

Best regards,
Sethu
Community Moderator | Technical Support Engineer
WithSecure™ https://www.withsecure.com/en/home

Soboknilch

Hello, the settings mentioned below have already been checked and adjusted - unfortunately this does not fix the error.

The guideline was also distributed afterwards.
What do you mean by "Force value..." button? Where should it be?

No new PS Server has been installed, an update from 15.30 to 16.01 has been carried out.
The key pairs should therefore have been transferred.

Soboknilch

Now something funny has happened...
It suddenly works as if by magic oO

I'll test everything again in peace and then give you more feedback.

Sethu Laks

Hi @Soboknilch

Thank you for confirming. We have noticed that you have also initiated a support ticket with reference number 05XXX131 for the identical issue. We recommend reaching out to our support team and providing the fsdiag logs if the problem persists. This will enable our support team to engage with R&D if further assistance is necessary.

Best regards,
Sethu
Community Moderator | Technical Support Engineer
WithSecure™  https://www.withsecure.com/en/home