LEM 5.4 w/ 5.3.1 Agents mis-reporting CPU architecture

Hey Jimmy,

Since the LEM Agent runs as a 32-bit service (in SysWOW64), we won't see anything as true 64-bit. All of my 64-bit systems say x86 as well. We'll want to get a feature request in for detecting beyond that, and I'll check with our (super) InfoDev team about creating a knowledgebase article so others get the benefit of your question.

On the tools issue, some tools won't start (or stay started) if the log path is drastically wrong (i.e. that directory and/or file don't exist), or if you're configuring something like a Windows tool on a non-Windows system (or the appliance). You can check the "SolarWinds Alerts" filter in Monitor for errors, and sometimes the log file on the agent (either agent.log or spoplog.txt).

With a little more details, I'm sure we can help (or at least say "you should check with support" ).

Doh, how did I miss that before?!  OK, good, I was hoping it was something as easy as a feature request pending.

On another note about the tools not starting...I may start another thread.  I actually had to manually clean up all the agents on our servers.  The jump from 5.3 --> 5.4RC --> 5.4Prod didn't go so smoothly for the agents.  When I went to the RC, I pushed all the updates to agent 5.3.1 through the console and it all appeared OK.  I tried the same when I went to the production version, but realized the agent version didn't change from the RC (I may want to add that to a feature request, always creating a version tick between RC and prod, regardless of program change).  I was having that difficulty with starting the tools so I went and investigated.  Well, the cleanup from the agent update from 5.3-->5.3.1 that happened in the RC was non-existant.  I had both versions, 5.3 and 5.3.1 on all clients, with 5.3 listed in Add/Remove Programs but the host reporting 5.3.1.  Some actually didn't have anything in the Add/Remove, but still had all the files and the dll's registered.  To fix, I did the manual 5.3.1 agent install, then uninstalled from Add/Remove Programs which cleaned up the directories, registry and unregistered the dll's, and then installed it again with the manual installer.

My tools now start without incident.

One thing I did not like about that process was that the reinstall did not remember which node it was, so it created a new one and left the old one as disconnected.  I had to further cleanup those disconnected nodes.  But, that may be by design, which is fine.  In that case, it behaved as expected

We've heard the request about increasing the agent version each release before. It's sort of a catch-22 - in order to do that today we'd have to push out an agent update, which is something we try to limit unless there's new functionality just to reduce the footprint of our upgrade. The downside of not doing that is the versions get out of sync. I think in the long term we'll need to push a "version" update that's just a reconciliation.

The second issue you reported does not sound expected (kind of a duh there). You shouldn't need to uninstall/reinstall like that to get to a new version.

The way it's supposed to happen is that the agent connects to the manager appliance after an upgrade, the appliance detects there's a new version available for that agent and sends the files to the agent, the agent downloads the files to disk, restarts itself, and moves them all into place. All of that is done within the context of the agent, so it doesn't delete and reinstall, it just downloads new libraries, restarts, and moves them into place.

If you've still got agents in that weird state, it'd be great if support could work with you to get the issue tracked down and escalated to our dev team.

(un)fortunately I resolved all the agent quirkiness already, everything is fine now.

But I guess this does bring me to a feature request then, which is to have the agents clean up after themselves when there is an update and then tweak the Installer cache to show the proper version in add/remove programs.  This is very reminiscent of back when Java wouldn't remove the legacy Java versions, but just keep installing the new ones, which we all found out causes a huge security hole that allowed attackers to comprimise a system through Java by using the old libraries/installs that existed on the client computers even if the clean version was installed.

This is an awesome system and for as complex as it is, it feels like a win when only 'cosmetic' things happen.  Good Job to you guys overthere!!!!!!!