Products & Services
Tuotteet ja palvelut
Produkte und Dienstleistungen
Produits et services
Produkter och tjänster
How to manually set the WithSecure Client Security Update server to to lets say 'guts2.fsapi.com' for example?
Hi @rdpk07 ,
Thank you for contacting WithSecure Community.
Did you mean to change to a different Policy Manager Server address ?
Or do you want the hosts to retrieve updates from a different proxy ?
Hi @rdpk07, were you able to solve this query? Do let us know if you need any help!
I would like to manually set the update server of an installed WithSecure Client Security to 'guts2.fsapi.com' WithSecure update server!
According to our R&D team, the Client Security is designed to retrieve definitions from the Policy Manager (PM) or Policy Manager Proxy (PMP). In most cases, overriding the guts2 address should not be necessary. However, if you have valid reasons to do so, here's how you can handle it depending on the version you are using:
For version 15.x, you can utilize the guts2ServerUrl. To add the additional java arg in the PM machine, navigate to HKEY_LOCAL_MACHINE\SOFTWARE(Wow6432Node)\Data Fellows\F-Secure\Management Server 5\additional_java_args and include the following: -Dguts2ServerUrl=https://guts2.fsapi.com/
HKEY_LOCAL_MACHINE\SOFTWARE(Wow6432Node)\Data Fellows\F-Secure\Management Server 5\additional_java_args
For PM version 16.x, the recommended property to use is wsGuts2RootServerUrl. Create the following string registry key: \HKEY_LOCAL_MACHINE\SOFTWARE\WithSecure\Policy Manager\Policy Manager Server\additional_java_args specify the Java system properties in the following format with the value:
\HKEY_LOCAL_MACHINE\SOFTWARE\WithSecure\Policy Manager\Policy Manager Server\additional_java_args
If you need to specify an upstream PM/PMP for this property, make sure to format it as 'https://<PM or PMP address>/ws-guts2'.
'https://<PM or PMP address>/ws-guts2'
I hope this information helps clarify the usage of these properties. If you have any further questions or concerns, please let us know.
Community Moderator | Technical Support Engineer
This is the current situation with the WithSecure Client Security 16.00 client:
I can't find in registry any registry value set to
Where does the WithSecure Client Security stores the value of the Update server?
Thank you for the reply.
May I know the reason you want to change this ? Is this host in an offline environment or isolated host ?
Thank you for your reply.
The host is an online environment.
There is installed Policy Manager 15.20, but for some reason the WithSecure Client Security Update server was set automatically to
after the installation of WithSecure Client Security 16.00.
So I was wondering where does WithSecure Client Security 16.00 keeps the string value of the Update server.
Are you trying to understand why it has different server than your Policy Manager Server , and disable the fallback to GUTS2 ?
So to answer your previous question, the settings settings are not stored locally on Client Security registry.
They are stored in our settings service, which is stored on the Policy Manager and duplicated on the local machine in the service files.
Even if you change the setting locally on the machine, it will return back once machine is connected to Policy Manager, so there is no point to try to find the setting value on the machine.
But give me some time as I am checking with our product developer.
Client Security requires Policy Manager of the same version or newer to function properly. By design Policy Manager will not allow you to import Client Security installation package of the unsupported version, but if you somehow succeed to upgrade the client before the server (i.e. by exporting CS MSI from another Policy Manager instance), that might explain why Client Security 16.00 is not connecting to Policy Manager 15.20 and thus falls back to the https://guts2.fsapi.com
If the Policy Manager is already upgraded to the 16th version, but client still refuses to connect it, worth checking another possible misconfiguration reason: it is now required to have Policy Manager server address defined at the Root domain level.
That's the case - I've exported CS MSI from another Policy Manager 16 instance.
I want to know where does the CS 16 takes the falls back value of
and where it is stored - in a registry key or in .ini file or whatever else?
@rdpk07, by upgrading CS before the PM you actually lost the client manageability and you must upgrade the Policy Manager to restore it back.
Default value is hardcoded and can be overridden from the Policy Manager only using the wsGuts2RootServerUrl Java system property (explained by @Sethu Laks earlier). But again, to pass it to the managed client you must upgrade Policy Manager upgrade to the latest version for at least 2 reasons:
Sometimes I have the following problem:
Let's say I have installed PM 16. After that I export CS 16 MSI from PM 16. After that I install the CS 16 MSI on the same machine.
When I start CS 16 and go to Settings > Update, the Update server points to: wait.pmp-selector.local/ws-guts2
So I was wondering if I want to change the Update server to
, how to do that or how to change the Update server to https://localhost/ws-guts2!
»after that install the CS16 MSI to the same machine on which is installed the PM16,«
Did you install both the Client Security 16 and Policy Manager Server 16.01 on the same machine? It is crucial to note that the Policy Manager Server is officially supported only on server editions. You can refer to the system requirement information for further details here.
»I was wondering how to change the Policy manager server to point to http://localhost/ws-guts2/or to https://guts2.fsapi.com/ ?«
Firstly, please ensure that the WithSecure Policy Manager Server address is correct/accurate and updated in the policy manager server prior to exporting the Client Security MSI.
If you have already updated the correct PMS (Policy Manager Server) address, you should be able to view the PMS address during the export MSI process from Policy Manager.
Moreover, please ensure that the host communication ports (usually TCP 80 and 443 by default) are actively listening.
If none of the previously mentioned solutions resolved your issue, we kindly request that you provide us with the wsdiag logs for further investigation. To facilitate this process, please contact our WithSecure support team and provide them with the wsdiag logs for a more in-depth analysis of the situation.