Agent install/Autoupdate Problem (win 2020r2-16.0.1)

[steffen]

recently we started to get strange behaviour trying to install latest FNMS Agent (16.0.1) on Windows:

If "Upgrade mode" is enabled (selected targets to latest version 16.0.1) we see following behaviour on Windows-only:

1.  initial installation looks fine
2. initial download of policy from beacon fine
3. update with new downloaded policy and agent update results in deleted reg.keys
4. subsequent communication to beacon is lost
5. after complete de-install + re-install steps 1)-4) are reproduced

it is not clear to me why the agent is updating after initial call home, because we are already installing latest 16.0.1 version to start with.

At least the following RegKeys getting deleted:

desc0 = SelectorAlgorithm val0 = MgsIPMatch desc1 = NetworkSense val1 = False desc2 = CheckCertificateRevocation val2 = False desc3 = CheckServerCertificate val3 = False
as well as all Download + Upload Servers

looking at the installationlogs somehow SelectorAlgorithms getting "reset to default "MgsRandom","MgsPing" ,"MgsADSiteMatch"  which cannot work since we have no DNS/ADSite in our ENV

as a quick WorkAround we changes "Upgrademode" to "do not upgrade automatically"under inventory settings inside the GUI.

now the initial Agent installation remains working withouth updates...!

(Flexerainternal Case: #02434472)

Greetings

Steffen

[ChrisG]

One thing to check here is that you do not have the following setting specified in the mgssetup.ini file that is used for the initial agent installation:

DESTRUCTIVEUNINSTALL = 1

If this setting configured at installation time then the automatic agent upgrade process may not work, with behavior like you have described being observed.

The DESTRUCTIVEUNINSTALL setting should only be enabled at installation time if you plan to use a bespoke upgrade process that will handle all registry settings being removed when the old version is removed, and install the new agent version and configure all registry entries to your desired values (i.e. like occurs on a fresh agent install).

[steffen]

Thanks a lot Chris!

yes we do have "Descructiveuninstall = 1". In the past we could manually deploy the agent and later down the line use FNMS to automaticly update to a new version once available - we did not identify issues like this before.

We certainly will disable this now and have a closer look here.

Thanks and greetings

Steffen

[steffen · Accepted solution]

In fact it looks like a know topic to me:

https://docs.flexera.com/fnms/EN/Status/Issues/March2021.htm where this is only reported for Cloud release 2020 R2.2 and not for on Prem 2020r2!

IOJ-2177310

Agent

Auto upgrade with previously installed mgssetup.ini containing DESTRUCTIVEUNINSTALL = 1 removes all ManageSoft HKLM data

Deploy a script to any Windows machines with the agent installed where DESTRUCTIVEUNINSTALL=1 was set in mgssetup.ini to either remove C:\Program Files\ManageSoft\mgssetup.ini or to modify the installed mgssetup.ini removing the DESTRUCTIVEUNINSTALL=1 entry.

[durgeshsingh]

Team,

We are using fnms 2020R2 onprem & we are also facing the same issue. We are going to apply work around to test. 

[EHacking]

We had this happen back in January, and the fix does work.

[mag00_75]

Hi@ChrisG 

Are there any way this could be configured in the auto-upgrade settings on the FNMS server instead of deploying a separate script that change the destructive..=0. Like a hidden policy setting or something?

We have had the auto-upgrade feature working before even with this setting, but now in 2020R2 it's not working. Our environment consist of several local active directories so getting all companies to deploy a change takes quite some time if we can't tweak FNMS to change the setting.

[ChrisG]

Unfortunately I can't think of any way to use FlexNet Manager Suite functionality to change existing configuration on computers where agents were installed with DESTRUCTIVEUNINSTALL=1.

I'm surprised to hear that you were able to use agent self-upgrade capabilities working in the past for agents with this setting enabled. I've never had success at doing that. It may be a hard question to answer, but it would be really interesting to know what it was about your setup that enabled this to work. I'm not aware of anything that would have changed in the 2020 R2 release about how the agent upgrade process handles this setting that would cause different behavior to previous releases (given the same configuration).

One option for you may be avoid upgrading the agents at this time, and wait until the 2021 R1 release is available. That release is currently planned to include a change related to the IOJ-2177310 issue that @steffen mentioned. The change basically causes the DESTRUCTIVEUNINSTALL setting to be ignored in this scenario, on the assumption that if somebody did happen to configure the setting at deployment time then that was likely not what should have be done.

[mag00_75]

We have so many different deployments, so can not be 100% sure about where&when we have this setting.

Great that it will be fixed in next release, then I will wait for that before I trigger all upgrades on Windows.

We will continue troubleshooting the issues we have with auto-upgrading linux agents which I'm sure should not have this setting, currently running the 2020R1.2  (even though we have on-prem).

[mfranz]

Hi @ChrisG,

A customer has an environment with the exact problem. Can you tell where the option actually takes effect? Is this stored in the registry?

We're looking for a way to defuse this bomb and hope a simple change in the registry may do the trick. There's not much documentation on this.

Best regards,

Markward

[steffen]

hi Markward,

as far as I know there is NO Registry Entries for this - its only a setting inside mgssetup.ini I'm not shure if you can change that afterwards - simply exchange the mgssetup.ini against a new one - while Agent remains running and installed.

@ Chris whats your opinion on this?

[ChrisG]

From memory I believe @steffen is right: I think the mgssetup.ini file that is used for the install is copied to the agent's installation directory, and the setting is then picked up from that file when the agent upgrade or uninstall operation is subsequently performed.

[durgeshsingh]

If we will replace with modified file. Will agent start taking upgrade or do we need to perform clean uninstall & install.

[ChrisG]

I'd certainly recommend doing some testing, but I don't think making (reasonable) updates to the installed mgssetup.ini file would cause any particular problems or unusual behavior with the agent upgrade.

[mag00_75]

Hi @ChrisG 

Is it enough that the beacons are running 2021R1 or does the Appl&DB also be on 2021R1 level to be able to bypass the destructiveuninstall?

[ChrisG]

The DESTRUCTIVEUNINSTALL setting is something that is used in the agent installer, so changes related to IOJ-2177310 discussed earlier in this thread depend on using the 2021 R1 agent version. The version of components installed on beacons and application servers don't affect this.

[durgeshsingh]

I did workaround on this & successful. With this setting agent will take upgrade but stopped reporting back to beacon due to unknown setting in ini file.

If you have targeted your agent upgrade run below PowerShell command remotely in all targeted server. It will start reporting back & it will one time activity. 

cd "C:\Program Files (x86)\ManageSoft\Policy Client\"
.\mgspolicy.exe -t Machine -o DownloadRootURL=https://beaconservername/ManageSoftDL -o UILevel=Quiet