A new Flexera Community experience is coming on November 25th. Click here for more information.
Hi Everyone, now that I have got your attention .. lol .. I just want to confirm what I had previously done to trigger these auto updates in terms of the "Log On As" Account for the Flexnet Beacon Engine Service. I use the "Beacon Version approved for use" setting in the Inventory Settings tab to control what version of software for the Beacons we use, that is straight forward and works just fine. We use the North American Cloud environment.
In the past since we use a "Service" Account instead of the "Local System Account" for the "Log on As" for the Flexnet Beacon Engine Service I have had to change the "Log on As" back to the "Local System Account" before triggering the Auto update or the update would fail, after the Beacon has upgraded, I went back in and changed the "Log on As" back to the "Service" Account. That worked just fine as I recall when I upgraded I believe last year to Version 16.1.0.19.
This brings us to yesterday, I followed the same process as above and triggered the auto update for my 2 UAT Beacons to version 17.3.0.6 following that same process of changing the "Log on As" user name. Not to drag things out too much but when I was looking at the Beacon Engine log monitoring the progress it was taking forever, like an hour and half sort of thing and it seemed to be downloading the packages just fine and claiming it was triggering the update but nothing was happening and then the process would repeat itself every 15 minutes or so when it received its updated policy saying to upgrade the Beacons again.
Long story short, I flipped the "Log On As" user back to the "Service" Account and it seemed to proceed with the update .. hard to say for sure if that helped or not. I struggled with the second one as well due to the fact that the .net version was sitting at 4.5 so I corrected that and things kind of proceeded similar to the first one but eventually by cycling the "Log on As" user back and forth it eventually upgraded ok.
As you can tell .. it was very messy ...
Does anyone know for sure whether it is still necessary to have the "Log on As" user for the Flexnet Beacon Engine Service set for the "Local System Account" before attempting any Beacon updates automatically. Back a few years ago it was suggested that you could leave the "Log on As" user to a "Service" account and it would update ok, but when the Service was stopped and started by the automated process, it would by default start the Service using the Local System Account but I found in my situation the process would fail if I left the "Log on As" user as a "Service" account.
I apologize for the novel but I wanted to give you the big picture, as this seems to be a challenge in the past for others as well using the Auto Update Beacon feature.
Thx as Always
Bruce
‎Mar 02, 2022 09:51 AM
I can't think of any definite reason why the upgrade would not work if the Windows service is running under a service account (rather than Local System), as long as the service account has network access (e.g. possibly with appropriate proxy configuration) to download the upgrade package and has local admin rights.
I'm not sure that helps to answer why you had problems, but hopefully it confirms at least some of your thinking.
‎Mar 03, 2022 06:07 AM
I can't think of any definite reason why the upgrade would not work if the Windows service is running under a service account (rather than Local System), as long as the service account has network access (e.g. possibly with appropriate proxy configuration) to download the upgrade package and has local admin rights.
I'm not sure that helps to answer why you had problems, but hopefully it confirms at least some of your thinking.
‎Mar 03, 2022 06:07 AM
Thanks Chris for your update ... really appreciate it !!
‎Mar 03, 2022 08:01 AM