Some users may be experiencing issues when trying to access customer resources like the Case Portal or the Product Licensing Center. Our team is aware of the issue and is working to resolve it. Click here for more information.
Hi all,
I have one beacon that is not detecting the TLS version 1.2 i have configured the registry reboot the server but still won't work, OS version is Windows Server 2019
2022-07-29 00:16:42,012 [Scheduler.ScheduledJob|download] [INFO ] Executing job: download
2022-07-29 00:16:42,012 [llers.BeaconController|download] [INFO ] Scheduled job triggered: sap-download.
2022-07-29 00:16:42,012 [load.PackageDownloader|download] [INFO ] .Net framework present: .NET Framework 4.7.2 or later
2022-07-29 00:17:52,918 [Services.PolicyService|policy] [INFO ] TLS version used:
I would appreciate some advices
āJul 29, 2022 02:17 AM
I don't think I understand what problem you're trying to solve, but I believe the "[Services.PolicyService|policy] [INFO ] TLS version used:" line of logging indicates the TLS version (if any) that is detected as being in use when connecting to the server identified under the following registry key on the beacon:
HKLM\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft\Common\DownloadSettings\ReplicatorParent\
Enabling "DEBUG" level logging in the C:\ProgramData\Flexera Software\Compliance\Logging\BeaconEngine.config file may produce additional logging in the BeaconEngine.log file showing details of what happens the protocol detection is performed.
āJul 29, 2022 02:40 AM - edited āJul 29, 2022 02:43 AM
I have enabled Debug level logging and i found this error
2022-08-01 00:01:00,639 [uler.StandardScheduler|IPC] [DEBUG] Key job: discoexport
2022-08-01 00:01:00,639 [llers.BeaconController|IPC] [DEBUG] Getting UDI triggers
2022-08-01 00:01:00,639 [uler.StandardScheduler|IPC] [DEBUG] Exporting current schedule udi_execution to XML
2022-08-01 00:01:00,639 [uler.StandardScheduler|IPC] [DEBUG] Found 0 jobs
2022-08-01 00:01:00,639 [llers.BeaconController|IPC] [DEBUG] Looping through tasklist
2022-08-01 00:01:17,041 [tionProtocolIdentifier|download] [DEBUG] Error while identifying the protocol used for communication. The operation has timed out
System.Net.WebException: The operation has timed out
at System.Net.HttpWebRequest.GetResponse()
at Flexera.SaaS.Transport.Core.CommunicationProtocolIdentifier.GetProtocol(Uri endPointUri, ICredentials credentials)
2022-08-01 00:01:17,041 [tionProtocolIdentifier|download] [DEBUG] Using the Suite URL to get the protocol used.
āAug 01, 2022 03:48 AM
It feels like there might be something in the network that is not allowing whatever communication is done at this point to try to determine the protocol version in use.
I believe this detection is for information only, and a failure to identify the version on its own won't cause a problem with other communications.
If you are encountering a failures elsewhere, I would start by focusing on the symptoms of those failures, not on the logging related to the protocol version. As @bmaudlin as noted, from inspecting various logs it appears to be common that the protocol version does not get reported in the logging.
āAug 08, 2022 04:55 AM
I just saw the following information published which might be related to what you're seeing here: Known Issue: Beacon UI may take a long time to open when the beacon's parent is accessed through a proxy, with BeaconEngine.log showing no TLS version detected and "Error while identifying the protocol used for communication. Unable to connect to the remote server" (IOJ-2161590).
āAug 10, 2022 04:26 AM
Hey @OvidiuManta,
I see a similar issue with our Flexera beacons some reflect the correct protocol and some show a blank as you have described, and have never really got to the bottom of why the logging shows this behaviour.
However from an actual protocol we have had it confirmed it is actually enabled from the various security scans that are run.
It's a strange one!
Ben
āJul 29, 2022 11:40 AM
User | Count |
---|---|
8 | |
6 | |
3 | |
3 |