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

Attached the error screen shot and beacon engine log files

For failures related to package downloads, the best log to check is the packageretriever.log; this is usually located in C:\Windows\Temp\Managesoft.

 

Any errors should appear in there.

(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.

Hi,

 

 found the  below error message:

=========

8016} ERROR: Error (s107m857)
[16/01/2020 8:40:03 PM (U, 0)] {8016} ----------------
[16/01/2020 8:40:03 PM (U, 0)] {8016} The web server or proxy from which ManageSoft
is attempting to retrieve the application
returned the following HTTP error message:

Error 0xE05001F4: 500 Internal Server Error

Contact your network administrator or the
originating site's Webmaster for assistance.

==========

in the log file and attached the same log file.

 

Please let me know how i can proceed further. i dont have clue to move to next step.

 

Thanks,

Dhananjayan M

Is this a child beacon i.e. is the server it's downloading from the inventory server or a parent beacon?

 

Also, I can see that it's downloading 2018 agents so I would also ask what version is the beacon and what version is on the parent server as we've seen issues where the FNMS version is not in sync on older versions.

 

If none of the above applies, I would recommend opening a support case as it will need a more in depth look at your environment than what we can easily do on the forum.

(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.

Hi,

We are having 5 beacon servers and all the servers having this issue. 2 days before only this issue started.

We are using 2018 R1 version of FNMS in our environment.

We can try to create a support ticket for this, tomorrow we are planning to upgrade 2019 R1 version.

We will wait.

Thanks for the help

Regards,

Dhananjayan M

 

Just to echo, and could be coincidence but my customer has the same issue as of today.  After some issues with the Master beacons, we rebooted them and now get the same error as described by OP.

Hi,

Sorry to jump in the conversation, but I have the same error, the only difference is that I receive this error on child beacons.

FNMS version 2019 R2, all beacon servers are running this version. 

Do you have some advise why this is happening to child beacons?

Same issue is seen on our Infrastructure. Parent and Child-relations seems to be affected after upgrading to 2019 R2.
please Review Case: #01975200

I'm working on this now with some of the developer teams that have experience with beacon packages.

Once I have an update I'll communicate back but thanks to everyone for letting me know it's not an isolated issue, that is very helpful information.

(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.

thanks MRRICHARDSON

Hi all,

Considering there are several versions impacted all at the same time, this suggests there could be something operating system related and the most likely cause is a Microsoft Update.  Testing on this is continuing but to help confirm or deny if this is a valid line of investigation, can I have confirmation from those impacted of the following information:

  1. What Operating Systems are the parent / child beacons running?
  2. Have any Windows Updates / patches been applied in the last 2 weeks or so?
  3. Can you try taking the URL from packageretriever.log and manually running that locally on the parent server and see if it works or if still fails (trying to rule out browser / networking issues).
  4. Are all of you using HTTPS or is anyone experiencing this on HTTP?

 

What we've found is that it's primarily .cab files that are impacted and so one option to temporarily get around this if you need to is to manually copy the files from the parent to the child beacon.  This isn't intended as a long term solution but if anyone needs to get this working urgently I'd recommend this approach in the short term.

(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.

Hi @mrichardson ,

 

Our implementation is like this:

 

App Server - Beacon 01 - Beacon 02 - Beacon 03

App Server - Beacon 01 - Beacon 6

App Server - Beacon 04 - Beacon 05

 

 

Beacon 01, 02, 03, 05  are Windows 2012 R2 Standard

Beacon 06 - Windows 2016

Impacted beacon by this error are Beacon 03 and beacon 05, strange thing is that Beacon 02 that is also a child beacon is not generating this error, also Beacon 05 which is a child beacon but is with Windows 2016

Related to what updates was applied I have no idea as the OS are managed by different teams

I  hope this information is useful for you, I will test the direct download of the failed package and let you know.

By the way I observed this behavior also before on FNMS 2019 R1 and with the upgrade to R2 the issue was not resolved.

 

Hi @mrichardson ,

I tried to download the .cab file that is generating error via internet explorer and I receive the same 500 error, our beacon implementation is a mix of https and http, this error in log file this error appear on across all reachable beacons, http and https, so it seems that is not related to https communication, or at least in my environment.

 

Thanks @adrian_ritz1 for doing those tests, we have a couple of theories that our developers are looking into however to help confirm if these are a possibility they've identified a couple of other pieces of information that needs validating:

  1. Are the beacon versions on 2019 R2 or are they earlier?
  2. If they are on 2019 R2, were the beacons upgraded before or after the application server?
  3. In the packageretriever.log file, do the files that fail have *_metapkg.ndc.cab as the format?

The answers to all 3 questions will help our developers to identify the correct line of investigation to follow.

(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.

Hi @mrichardson,

  1. Are the beacon versions on 2019 R2 or are they earlier?
    • All beacon servers are 2019 R2
  2. If they are on 2019 R2, were the beacons upgraded before or after the application server?
    • I updated 1st application server, and then from WI ui I pushed all beacons to the new version
  3. In the packageretriever.log file, do the files that fail have *_metapkg.ndc.cab as the format?
    • yes, seems that all files with *_metapkg.ndc.cab return error

Thanks @adrian_ritz1,

For yourself and all others on 2019 R2 we think we know the root cause, I'm working internally with the relevant teams to put together some instructions on how to rectify this.

 

For those on 2019 R1 or earlier, if you have deployed the 2019 R2 agents in your environment then you will hit the same issue as those on 2019 R2 application servers so this is something we're working on.

 

For those where agent packages are below 2019 R2 i.e. are lower than 14.0, please reply back and provide Operating System details and also confirm when the issue started occurring as you are going to be facing a different issue.

(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.

Hi,

could you provide some more insight about what you think could be the root cause and is there anything we could do upfront in preparation to support solving this issue?

Thanks & best regards

Oliver 

We're currently validating but it's believed to be related to the signing of agent packages that we added in 2019 R2 for security purposes.

We're checking this but the current suspicion is that if the parent beacon was not on 14.0 before it attempts to download these packages then it will stop the download attempts even after the beacon is upgraded.

If this is the case, a PowerShell script is available that should reset this and we're currently working out if steps such as setting agents to not auto-upgrade prior to upgrading the app server would help or not.

 

I'll provide an update once we've validated this theory.

(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.

Hi @mrichardson,

Has there been any update on this topic after your post from Monday (Feb 20th)?

As you probably know, roll-out and upgrade of FNMS agents is blocked for major customers (REF: Support Case #01975200).

Best regards from Munich - Klaus

Hi @dtag-klaus,

An official workaround and solution is still being worked on however in the short term, one option which should work (although reduces security so is not ideal) is to do the following on the parent beacon:

  1. Open registry editor and navigate to [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\ManageSoft Corp\ManageSoft\Launcher\CurrentVersion]
  2. Locate the "VerifyCatalogSigned" string
  3. Set string to "False"
  4. After exiting registry editor, restart the Beacon Engine service.

This should allow the packages to download to the parent beacon although it means it's not downloading the signed versions of packages so if this a requirement for you I would recommend waiting for the official workaround; however if your main priority is to get up and running any way possible, this may help.

 

Thought it best to give the option for you (and others) to decide for themselves.

(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.