Error "There is a problem on the beacon. The beacon could not determine if an upgrade is required."

[ChrisG]

We have recently upgraded our FlexNet application server from the 2017 R1 release to 2018 R2, and configured settings so that our beacon should automatically upgrade to the new release (version number 13.1.1.712). However the beacon is not upgrading itself automatically. The BeaconEngine.log file on the beacon shows the following error indication:

2019-04-09 00:09:23,237 [llers.PolicyController|policy] [ERROR] There is a problem on the beacon. The beacon could not determine if an upgrade is required.

A more complete extract from the BeaconEngine.log file is given below.

We cannot find any other logging or indication of what may be causing this. Has anybody come across something similar previously and have ideas for troubleshooting?

Thanks!

2019-04-09 00:09:23,002 [Scheduler.ScheduledJob|policy] [INFO ] Executing job: policy
2019-04-09 00:09:23,002 [llers.BeaconController|policy] [INFO ] Scheduled job triggered: utils-policy.
2019-04-09 00:09:23,002 [Scheduler.ScheduledJob|download] [INFO ] Executing job: download
2019-04-09 00:09:23,002 [llers.BeaconController|download] [INFO ] Scheduled job triggered: mgsbi-download.
2019-04-09 00:09:23,002 [mmon.BeaconPolicyCache|policy] [INFO ] Loading beacon policy from 'C:\ProgramData\Flexera Software\Beacon\BeaconPolicy.xml'
2019-04-09 00:09:23,002 [mmon.BeaconPolicyCache|policy] [INFO ] Certificate configurations not found.
2019-04-09 00:09:23,002 [psClientSecurityPolicy|download] [INFO ] Security protocols Tls, Tls11, Tls12 are in use.
2019-04-09 00:09:23,002 [ownload.DownloadClient|download] [INFO ] Downloading item 'business-importer-example-csvs' using URI 'https://processingsvr.mydomain.com/inventory-beacons/api/download/business-importer-example-csvs'.
2019-04-09 00:09:23,002 [psClientSecurityPolicy|policy] [INFO ] Security protocols Tls, Tls11, Tls12 are in use.
2019-04-09 00:09:23,002 [Rules.PolicyClient    |policy] [INFO ] Downloading rules using URI 'https://processingsvr.mydomain.com/inventory-beacons/api/policy/?BeaconUID={1F6015E2-4959-4C04-82BB-3357AE37DC36}'.
2019-04-09 00:09:23,237 [Core.HttpClientBase   |policy] [INFO ] Server reported item is not modified. No download occurred for request https://processingsvr.mydomain.com/inventory-beacons/api/policy/?BeaconUID={1F6015E2-4959-4C04-82BB-3357AE37DC36}.
2019-04-09 00:09:23,237 [Services.PolicyService|policy] [INFO ] No new rules were downloaded (Current policy revision # 526).
2019-04-09 00:09:23,237 [llers.PolicyController|policy] [ERROR] There is a problem on the beacon. The beacon could not determine if an upgrade is required.

[Graemehin]

We had this error with one of our APAC customers recently and a manual upgrade of the Beacon resolved the issue.

[mengmeng_ge]

The original issue is that the beacon server cannot upgrade itself due to an incomplete download of the newer beacon installer.
The original issue got resolved after the customer connect the beacon server to the Internet directly to bypass all their firewalls and proxies.
(Apparently, their FW and/or Proxy somehow breaks the download of the beacon installer. )
Chris knows this original issue and he pointed out that this is probably a customer network environment related issue.

The new issue observed here is when the beacon failed to download the newer version installer but is trying to upgrade itself, the upgrade always fails.
In this situation, all scheduled inventory rules will not be triggered and left no message in beaconengine.log for troubleshooting.
It took me more than a full day to test and figure the root cause out.

After the beacon server is upgraded automatically from 16.0.1 to 16.2.0, the issue does not occur in my test environment.
My gut feeling is the issue only occurs when the beacon is trying to upgrade it to a newer version.
Considering 
- there is no fix in 16.2.0 https://docs.flexera.com/fnms/EN/BeaconChg/index.html#BeaconChangeLog/BCL_TheLog.html#BcnChg_16.1.0__16-1-0-Fixes
- the issue did not occur in Feb with beacon 16.0.1. (the new version beacon 16.2.0 was not released in Feb)
- The issue is observed after the new beacon 16.2.0 released (auto-upgrade is triggered on the beacon server)

I guess that maybe the beacon has some logic to suppress all scheduled inventory rules to be triggered if it is in the pending upgrade status.
If the beacon somehow (like 02375818 ) fails to upgrade itself infinitely, then all inventory rules will never have a chance to be triggered by schedule.

Can you follow with the engineering team to confirm if the observed behavior is expected and by design?
If yes, can you raise a doc enhancement request to add the description of this behavior to the online help or a KB article?