Ican however install the agents manually, and have been doing so successfully most of the time.
I have been doing this via the route suggested by Support of copying the c:\programdata\solarwinds\agent\ files across from my Main Polling Engine to the target machine and then running the agent install msi locally. (Apparently this avoids issues with copying the plugins across networks which can cause hanging).
1. Restart of the Agent Service on the server
2. Restart of the Agent Service from the Orion Console
3. I have run a plugin report and can view the versions (they do look old - but others with the same version are working fine).
This typically occurs when there are two or more network interfaces in the machine, one of which is unused but is ordered higher (or lower depending upon perspective) than the interface that is active. To change the IP address the Orion Agent uses, simply edit the node properties, click 'Select IP Address', select the radio button for the 'real' IP address of the machine. Next, click the 'Select IP address' button and the 'Submit' button on the 'Edit Properties' page to save your changes.
Thanks, I didn't realise I could update it without admin on the server, that's very helpful.
I will attempt this when I'm back in the office next week.
I agree, it does seem that I must have older plugins somehow, even though the agent is reporting 2.4.4.2285 which is the agent that goes with 2020.2.4 as far as I understand.
Update - The server was rebooted a few times over the weekend before I had a chance to attempt the update and now 'completed' the install and has the correct plugins, so I've not had a chance to try the update of the agent.
Annoyingly a second server was in a similar state (reported as working, but when I looked to run the choose resources job it stated 'installing software').
I tried restarting the agent from the SW GUI and it has reported "Restarting" ever since.
Is your second machine running Windows? If so, it sounds like the Agent is awaiting a reboot of the server to finish the install/upgrade of the .NET Framework. The Agent itself is written in C++, but many of the Orion plugins are written in C# and therefore require the .NET Framework to be installed before certain jobs will function. When you click List/Choose resources, those plugins and their plugin dependencies are then deployed to the agent.
Use the SolarWinds Installer to install and upgrade SolarWinds Platform or Orion Platform products. With one installer, you can install or upgrade multiple products. You can also install or upgrade scalability engines (additional polling engines, additional web servers, and high availability servers).
Also use online installation to install a scalability engine, even in environments without Internet access. Installing a scalability engine doesn't require Internet access. See Install an additional polling engine, additional web server, or HA server for details.
A dedicated, separate SQL Server Standard or Enterprise database (physical or virtual machine) must be available on the SolarWinds Platform database server. For the requirements for the SolarWinds Platform database, see the SolarWinds Platform System Requirements. For Microsoft SQL Server installation instructions, see the SQL Server Installation Guide.
SQL Server Express is approved only for evaluations. This option installs SQL Server Express locally and then installs SolarWinds Platform products as quickly as possible using global settings. You select only the installation location and your preferred product language.
SQL Server Express has a 10 GB storage limit, which is not sufficient for many SolarWinds Platform deployments. If you later require a larger database, you must migrate to a SQL Server Standard or Enterprise database.
The installer performs a system check to ensure that your environment meets the minimum requirements and to look for any potential problems. The results of the system check are displayed on the Installation Report page.
Switch user: Provide credentials automatically detected as either SQL or Windows credentials, allowing Windows authentication for the initial setup even if the SolarWinds Platform server is not joined to a domain or the current account does not have permissions to the database server.
I'm new to SolarWinds. I just did a new install of SAM on a Windows 2016 server. I elected to install to the E drive instead of the C. Everything went fine without error and I can log into Orion without issue. We anticipated needing an additional ape because of the amount of monitors we need. So I setup another server in the same vlan as the Orion server to act as the ape. There is no connectivity issues between the two servers. When I run the Orion installer on the ape, select Add a Scalability Engine, add the requested information, and select next I get an error.
I additionally ran through the steps in this kb for installing an ape and that has issues also. I'm concerned that an out of the box installation is already having significant issues - _Center/Orion_Platform/Orion_Documentation/SolarWinds_Orion_Installer/Install_an_Additional_Polling_Engine_Additional_Web_Server_or_HA_server
You wouldn't happen to have the windows firewalls running would you? Try turning them off and see if this fixes the problem. The admin guide lists all the ports you need enabled if you want to create a rule. I can't imagine how this could happen unless some ports are being blocked.
It isn't a firewall issue. I think I figured it out. During the initial install of SAM it requests for a location to install the bits. I changed the location to E:\Program Files (x86)\SolarWinds\Orion from the default. I didn't create this location though. I assumed it would create the directory during the installation process. It didn't though and installed everything into C:\Program Files (x86)\SolarWinds\Orion. The installer somehow must have configured something in the application for the E drive though because when I went to run the installer for the additional polling engine it was complaining about not being able to get installer metadata. I presume it was looking for something on the E drive. So I started over and manually created the directory E:\Program Files (x86)\SolarWinds\Orion and ran the install again. It installed all the components to the E drive as I verified there was actually folders and files there. I then went to the server where I wanted to install the additional polling engine and ran the installer and it installed successfully.
There must be something weird about your environment because I can assure you, it normally does create the install directory on it's own. I've installed in at least 100 environments and never had an issue with it completing the install, but not actually creating the directory. This gets back to the reason why they recommend you execute the installer under a local admin account on the server, to minimize the chance of unusual security or access policies jamming things up.
Interesting, to be fair I haven't installed a fresh environment since mid November, but it definitely created the necessary directories automatically on 12 different servers I installed that day. Maybe something different in the latest release of the installer, but this is still pretty unusual.
Just wanted to shoot you guys this message about the new agent. Not sure if this is by design or if this might be a bug of some type. I'm testing the new SAM agent installation in our environment and ran into a small snag. Luckily there is a workaround so it isn't too big of a problem. Here is the story:
I'm running the installation manually and at the "Orion Server Connection Details" screen I type in my Orion admin credentials. We use Windows domain accounts with admin rights to Orion but they don't work. I tried both the "domain\userid" and "userid@domain" formats with no success.
What threw me for a loop was the text "The server name or address could not be resolved". I could PING the IP address of the Orion server just fine and DNS was resolving the IP address and hostname of the Orion server just fine. Also, just in case, I used telnet to do a port check for 17778 too which was successful - so I knew this wasn't a network\firewall connectivity issue.
3a8082e126