Loading
Archiving Service not starting anymore since SLM 9.14.1

Hi,

 

with this message I just want to share with you an issue we are facing since our migration to SLM 9.14.1.

 

As you can see on screenshot below, we are unable to archive computers due to the following error: "Archiving service is not up and running!".

 

Capture 

Having a look to this service we notice that it is actually running but the following error appears in the logs:

 

System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Extensions.Configuration.Binder, Version=3.1.9.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The located assembly's manifest definition does not match the assembly reference. (0x80131040)

 

In the end, it turns out that SLM 9.14.1 is shipping the wrong Microsoft.Extensions.Configuration.Binder.dll version.

The Archiving service is expecting version 3.1.9.0 when version 3.1.8 is actually installed.

 

Capture 

We restored the corresponding DLL from our Prod system running SLM 9.12.1. Indeed, in SLM 9.12.1, this DLL has the correct version.

 

So, if you plan to move to SLM 9.14.1, take a backup of the file Microsoft.Extensions.Configuration.Binder.dll located in <your path>\Snow Software\Snow License Manager\Services\Archiving\ ... just in case you need it afterwards.

 

Kind Regards

 

Christophe


  • Hi Christophe

     

    I encountered the same issue after updated to 9.14.1 last week. I indicated this in the product release group... Snow quickly fixed the issue and released the update to stop this issue from occuring again. I've since upgraded 3 systems without this issue since the re-release. You can always reset the updaterevision number in the registry and then run wsus again to update to 9.14.1 with the fixed package

    Expand Post
    Selected as Best
  • Hi Christophe

     

    I encountered the same issue after updated to 9.14.1 last week. I indicated this in the product release group... Snow quickly fixed the issue and released the update to stop this issue from occuring again. I've since upgraded 3 systems without this issue since the re-release. You can always reset the updaterevision number in the registry and then run wsus again to update to 9.14.1 with the fixed package

    Expand Post
    Selected as Best
    • I also encountered the same issue last week and opened a ticket. But again the community came up with a workaround/solution which works for me too quicker then Snow support does 😉 So thanks @Adam Davies​ .

       

      But I'm disappointed that again an update is released by Snow which causes issues at the customers site where I would expect Snow to find these issues during there testing before releasing....

      Expand Post
  • I had the same problem after updating to 9.14.1.

     

    Why SNOW doesn't correct the 9.14.1 binary download and let all customers fall in this trap?

     

     

    Expand Post
  • Hi Markus,

     

    according to @Adam Davies​, this issue is supposed to be solved but 10 days ago, I have downloaded the same package again (with a reset of the updaterevision) but It did not change anything for me.

     

    Kind Regards

     

    Christophe

    Expand Post
    • Hi Markus,

       

      I tried the ONLINE method but it failed with some kind of connection timeout. Then, I tried the OFFLINE way which went well (except that it did not fix the issue with Archiving service).

       

      While reading the SUS logs today, I noticed the following:

      2021-07-19 13:51:20,645 [InstallationWorker] INFO SnowSoftware.Update.ProductUpdate [(null)] - Verifying digital signature for D:\is\PROGRAMFILES\Snow Software\Snow Update Service\Downloads\SnowLicenseManagerEnterpriseEdition\485.zip 

      2021-07-19 13:51:25,764 [InstallationWorker] INFO SnowSoftware.Update.ProductUpdate [(null)] - Update v 9.14.01 for Snow License Manager Enterprise Edition (UR# 485) was already downloaded and verified against expected checksum.

       

      Maybe, I should have done some cleanup before retrying the update ;-)

       

      Anyway, end of this week, we plan to roll out 9.14.1 in our Production environment. I will be able to verify if this issue is finally fixed.

       

      Kind Regards

       

      Christophe

      Expand Post
  • Hi Christophe

    as I got this error also by OFFLINE update @Antony Parker​ (EMEA resolution manager) is checking if sth. is wrong in the internal correction process of SNOW.

     

    In the meanwhile I always check the community before doing an update. A little self-insurance 😀

     

    I remember that I had the same issue like you, when I switched from OFFLINE to ONLINE and back to OFFLINE.

    The solution by SNOW support was to delete the ONLINE download packages.

     

    Best regards

    Markus

    Expand Post
  • Hi Markus,

     

    Thank you for the hint ... I will keep it in mind for next upgrade 😁

     

    Kind Regards

     

    Christophe

    Expand Post
  • Hi all,

    as we are hitten by this update problem as well (did Offline-Update) could someone PLEASE detail on what to do _exactly_ to:

    a) to delete the ONLINE download packages

    -> location/directory to prune?!

    is it: "C:\Program Files\Snow Software\Snow Update Service\Downloads\SnowLicenseManagerEnterpriseEdition\" ?

    b) reset of the updaterevision

    -> ist it sufficient to set

    HKLM\SOFTWARE\Snow Software\Snow Update Service\Installed Products\SnowLicenseManagerEnterpriseEdition\UpdateRevision

    to '484' (which should reflect 9.14.0 ?!)

    c)

    What about the registry keys of

    DatabaseVersion

    and

    ProductVersion

    Do I need to adopt them as well?

    Expand Post
  • I can confirm, this bug is SILL in there!

    TODAY (11.08.2021) I created and downloaded an OFFLINE-Build to update to 9.14.01

    (by setting registry back to 9.14.0 with 'UpdateRevision' = 484 and ensuring SUS did not have old update files in it's directory!)

    But AFTER doing the update Archiving Service still fails. -> Aaaahgh#*&$

    The DLL 'Microsoft.Extensions.Configuration.Binder.dll' is still at version 3.1.8.

    This DLL is part of the 'CoreFramework3.1' which is copied over to several of the SLM Services directories during update process.

    Investigation of the Offline-Update-Package-Content proofed that it has that old file in 'CoreFramework3.1' and as such possibly other SLM serices may be affected as well!

    Conclusion:

    Current delivery of SLM 9.14.01 Update Packages is STILL broken!

    (at least for the offline-packages, couldn't check wich online as it constantly failed to download the update package not with nor without CDN ckecked).

    @Snow: Please take over and mitigate as quick as possible...

    Expand Post
10 of 16

Related  Product Forums


                     → Flexera One



                      → Snow Atlas



                      → FlexNet Manager



                      → Snow License Manager



                       → App Broker


       Need help finding an answer?


        Ask a Question →


Loading
Archiving Service not starting anymore since SLM 9.14.1