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

Third-Party Agent Deployment Question

Hi all ...

I have a question about third-party agent deployment.

Here's my use case:

  • A Windows computer already has the 2021R1 version of the agent
  • The already-installed agent points to Inventory Beacons tied to a DEV server.
  • We used SCCM to push the installation command of the 2021R1 agent to this machine.  (Yes, the agent versions are the same.)  With this package, a bootstrap file was supplied that points the installation to a PROD Inventory Beacon.

My expectation was that the installer would reinstall the same agent version and then point the agent to the production inventory beacon, get the list of all PROD inventory beacons, etc.

However, when I checked the following morning, I didn't see this computer's inventory uploaded to the production FNMS.  I still see it reporting to the DEV FNMS.  I suspect that the installer detected that the same version of the agent already existed on the machine and didn’t do anything.  (At the moment, I assume the SCCM push of the command was successful and am checking into that as well.)

Is an upgrade (or downgrade) triggered only if the already installed version is different from the one being requested?  


(7) Replies

Hi Mark,

In all likelihood the machine still has the existing registry entries for the DEV beacons.  It should also now have the Prod beacon(s) but the agent will determine the first beacon to communicate with (based on availability, ping response time, etc) and only upload inventory to that beacon.  You may want to develop a separate SCCM "package" that would eliminate any of the Dev beacon's from the registry prior to running your new SCCM Prod package on the machine.


Hi Darren ... Would I also see the entire beacon list (PROD and DEV) in the tracker.log file when the upload decision is made?


Hi Mark,

Yes, you would see each of the beacon servers the agent is aware of in the "Prioritizing servers for upload" section of the Tracker.log.  The server with the lowest priority value would be the first beacon where an upload is attempted.


To kind of close the loop on this one ...

In my case, it turns out that SCCM never activated the agent MSI because SCCM found the same version of the agent already installed and considered the deployment "compliant".  The MSI itself never ran.  This makes sense - if the version of the agent is the same as that being deployed, the assumption should be "hey the agent is already installed, nothing to see here, move along ...".

So I did some experimentation with just the MSI and without SCCM.  If I start out with 17.1 and attempt the “upgrade” to the same version, nothing changes.  The MSI does run though, and the msiexec log indicates that the existing version was changed, though nothing really was changed.  The revised mgssetup.ini does not get applied.  However, if I uninstall the agent first (msiexec /x) and then install (msiexec /i), I get the desired change to the inventory beacon list (because the install here is a new install) - the mgssetup.ini file does get applied.

So the answer to my own question:  "Is an upgrade (or downgrade) triggered only if the already installed version is different from the one being requested?" is YES 🙂


Thanks for the follow-up Mark.  I am curious if the uninstall removed your Dev beacon registry entries or if they remained after the "new" installation using the updated mgssetup.ini.

Hi @darren_haehnel ...

Yes, the DEV beacon entries were all removed and replaced by my PROD ones.

I also specified this in my mgssetup.ini, which is likely why it worked for me:


The comment for that variable is:

If set, forcibly removes any Tracker, Launcher & Schedule Agent registry keys under HKLM during uninstall.

Some discussion of this variable can be found here:  Flexera Agent Leftovers After Uninstallation - Community



Do an SCCM package to delete the registry keys under UploadSettings and everything but Bootstrap Server. 

Modify the host REG_SZ under the bootstrap server with your production server.

either reboot or stop all of the Flexera services and restart them.