cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Last download of packages for managed devices failed. Check the log file on the beacon server.

 

Hi Team

On all my beacons it shows an error "Last download of packages for managed devices failed. Check the log file on the beacon server."

I have verified the log file in the path but unable to find any error message.

C:\ProgramData\Flexera Software\Compliance\Logging\BeaconEngine

Please help me how we can solve this error.

Screen shot also attached.

(33) Replies
 
After checking on freshly installed FNMS 2019 R2 Beacons as well as on Beacons that have been upgraded to FNMS 2019 R2, the Registry setting for 'VerifyCatalogSigned' was set to "False" under HKLM\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft\Launcher\CurrentVersion already.

It looks as if this is the default setting. Beacons using this setting are having problems with downloading the packages for the Beacon and for Flexera Agents. My colleagues from other Softline teams working on other FNMS projects have recently opened another support case (#01977177) for this problem.
 
Looking for the official workaround or official solution then.

Hi @mrichardson,

I checked also this settings in customer environment, and is set by default to False, and the beacons still not working and returning error. I checked also in master and child beacon.

Our dev and support engineers are working on a short term solution, we believed we had one but it didn't work as effectively as anticipated so it's being updated now and then we'll re-test it.

As soon as we have something, I'll update this thread.

After that, we'll look into a longer term solution on how to prevent this happening altogether however the priority right now is to get everyone back up and running again.

(Anything expressed here is my own view and not necessarily that of my employer, Flexera)
If the solution provided has helped, please mark it as such as this helps everyone to know what works.

For anyone that has been experiencing 500 errors on their child beacons attempting to retrieve packages from a parent beacon, and the parent beacons are configured to use IIS as a host, please try running the attached PowerShell script on parent beacons _only_. (Extract MetaPkg_Perms_Workaround.ps1 from the attached zip file.) The script needs to be run from an admin PowerShell prompt.

The script will attempt to correct the permissions on files that are named ending in _metapkg.ndc.cab. The permissions on this file are preventing access when using IIS as the beacon web server.

Once the permissions are corrected you should be able to manually download the _metapkg.ndc.cab files from a web browser. If this succeeds, the package retrieval should start working for child level beacons.

Please let me know if this helps.

In addition to the apported information:


In a Parent beacon - Child beacon configuration, when parent beacon is updated, the packages are downloaded to the distribution\cache\common directory (ie. "c:\ProgramData\Flexera Software\Distribution\Cache\Common\"). Child beacon will search for packages into the Stagin\common directory (ie. "c:\ProgramData\Flexera Software\Staging\Common\"). For some reason the packages update procedure of parent beacon does not put the metapkg files into this directory. So, child beacon package retriever procedure fails.

Some time ago, I have made a ps1 script that must be run in the parent beacon in order to copy the metapkg files from Distribution\cache\common directory into the stagin\common directory. After the execution of this powershell script, child beacon is propertly updated

I have attached the script in a zip format file. Is a very simple ps script, be free to adapt the script as you need

Hi,

I can see that this solution is a workaround. But it isn't a Fix:

Once you've executed the script (you mentioned) on a Parent - and if you don't force the Child to update by calling its Beacon-GUI or other equivalent Method manually, the script will not work.

After a specific time and during next iteration of "upgrades" from Main-Server, the information will be lost on the Parent and therefore not inherited to the Childs again (overwritten by previos file-settings from Server?). Can you please investigate in that direction. If possible for Multi_tenant Env. as well?

It seems like the Chain is broken.

We also figured out, that Child-Beacons are able to download the latest Packages after doing those steps, so downloading Packages from parent seems to be OK for Child, but in a specific time (10-15 min according to the config) doing manually.

On the other hand, Server-GUI is not getting a reply that the package has been downloaded successfully and therefore displaying an "error - last download...." to the user for this Child.

So in our opinion there is a false-positiv message represented on Server-UI for child-beacons, even if thou they are able to download the Packages.

 

regards,

Matthias - Deutsche Telekom SAM Team

Yes, this is a workaround that was identified by Flexera support staff to palliate the effect of this problem in our environment. I only have written the script in order to make the task easier (the alternative was manually to copy the packages one to one from one directory to the other).
In our case, FNMS is in cloud mode: FNMP is disposed on the Flexera cloud and the two beacon server (parent and child) are installed at customer side. Both beacon servers are configured to automatically shelf-upgrade (Upgrade mode: Always use the latest version)
This is an important factor, because if you haven't configured your beacon servers to auto-updated, by keeping a specific version, the problem will not be present in your environment.
When each Beacon Server ask his parent about policy updates, it check it for upgrades packages as one of the first phases of the parent-child communication and, if upgrade packages exist on the parent Beacon Server, the child Beacon Server will try to download them and apply the upgrade. In this scenery, child Beacon Server fails to update because the packages are not found and it adopts an "out of date" status that will be translated as “unconnected” by the platform. Because the parent-child communication finishes with an error, the child Beacon Server does not get her policy file from parent Beacon Server. So, every time FNMS (on-cloud) is updated, we need to run the script on the parent beacon server and restarts the beacon engine service in the child Beacon Server. After some minutes, Child beacon server is in the appropriated level.
About a false-positive in the platform console, you can test the version of each beacon component by starting the beacon console. The child Beacon Server will be in an older version that parent beacon server. Even, agents associated to the child Beacon Server will not be updated because packages inventory includes the ones for agent upgrade. Of course, if you introduce changes on the discovery and inventory rules, these changes will not be updated on the child Beacon Server

Regards

Hi jlvico ,

many thanks for your reply.

 

Unfortunately, the script(s) doesn't work for us.

The script(s) assuming to have a file "authcode.cab" to be present on Beacon-level. But in Fact, this file is not present. I've checked my complete environment and this specific file is not available on Beacon-side.

I also assume, Flexera managed to provide a Fix for this by focusing on their own-hosted-systems (?) like a test-env. But not ensuring the functionality "in a global scale" - Thus, I've received several script - from support within an open Case - pointing out this issue - but doesn't solve our issue.

 

Hi jlvico ,

many thanks for your reply.

 

Unfortunately, the script(s) doesn't work for us.

The script(s) assuming to have a file "authcode.cab" to be present on Beacon-level. But in Fact, this file is not present. I've checked my complete environment and this specific file is not available on Beacon-side.

I also assume, Flexera managed to provide a Fix for this by focusing on their own-hosted-systems (?) like a test-env. But not ensuring the functionality "in a global scale" - Thus, I've received several script - from support within an open Case - pointing out this issue - but doesn't solve our issue til now.

Hi Matthias

The original powershell script that was sent out had that issue, there was a new one that was created that has corrected the issue for our other customers, that i believe that Josh has put on this thread. I believe you had a ticket around this, and since running this ps1  script it has resovled the issue on your master beacon, but now you are having an issue with your child beacon getting 404 error messages and timing out. Which was a known issue, and has said to be rectified. I did message you on the ticket to see if you are still getting the 404 error on your child beacon. 

Many Thanks,

Matt 

If you find my answer useful please give kudos, if my answer solves your issue, please make sure to mark as solution

@joshstechnij wrote:

For anyone that has been experiencing 500 errors on their child beacons attempting to retrieve packages from a parent beacon, and the parent beacons are configured to use IIS as a host, please try running the attached PowerShell script on parent beacons _only_. (Extract MetaPkg_Perms_Workaround.ps1 from the attached zip file.) The script needs to be run from an admin PowerShell prompt.

The script will attempt to correct the permissions on files that are named ending in _metapkg.ndc.cab. The permissions on this file are preventing access when using IIS as the beacon web server.

Once the permissions are corrected you should be able to manually download the _metapkg.ndc.cab files from a web browser. If this succeeds, the package retrieval should start working for child level beacons.

Please let me know if this helps.


@joshstechnij 

your script works fine, thanks. But, we've 7 out of 30 Beacons where this error  where this error occurs repeatedly after the file permissions have been corrected. It cannot be the parent-parent beacon, because other child beacons do not have these problems. Do you still have an idea why the permissions change again and again or how to counteract this.
Can it help, if we delete the complete Common Folder incl. all files on the faulty parent beacon and he has to download all packages incl. permissions again?

UPDATE: Delete the whole "Package" folder and our faulty parent beacon and forced a re-download from his parent (which is fine, because others download the files successfully). The problem still exists, the file permission for all ndc.cab files is different from the rest, this causes the error 500.

Any Ideas?

Best, Dennis

Hi Dennis,

In a recent project, we have been able to work around this by running the PowerShell hotfix on all Beacons on a schedule.

You can use the Windows Task Scheduler to run the following command every 10 minutes:

PowerShell -ExecutionPolicy Bypass <path-to-the-ps-script>\MetaPkg_Perms_Workaround.ps1

Assuming that packages are downloaded from the parent Beacon (or from the Inventory Server) to the current Beacon approximately every 15 minutes, the PowerShell script will fix the permissions on the CAB files that have been downloaded. This will prevent the 500 Error on child beacons downloading the packages and CAB files from the current Beacon.

Obviously, the user account configured for running this task should have Administrator privileges on the Beacon. Even if the user has Administrator privileges, the "-ExecutionPolicy Bypass" command line option is needed when running a PS script from Windows Task Scheduler.

Of course, this should be considered as a temporary workaround until a final fix for the problem becomes available in the upcoming FNMS 2020 R1 release.