This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Capabilities without agent?

I'm curious as to what kind of information can't be collected if a server/workstation doesn't have the agent installed. Are there any other features lost if the agent isn't present?

  • Hi, Quang.

    Agents are used to monitor events that are logged by the computers on which they are installed. Local events such as logons and logoffs, as well as certain change management events like software installs and changes to local policy are the types of events collected by LEM Agents. Once in place, the LEM Agent is also used for active response on that computer. These responses are fully configurable and can range from logging off a user to shutting down the computer or even disconnecting its networking.

    That's not to say, however, that the LEM Agent is the only way to collect useful data. Other types of traffic that are logged remotely, like web traffic, for example, can be monitored without a LEM Agent, but they require a tool on the LEM Manager to normalize the traffic from elsewhere on your network (firewall, proxy, etc.). The most important thing to remember is that the LEM product is log collection tool first and foremost.

    In addition to "losing" local events that would be collected by a LEM Agent if it were installed, you also lose its powerful USB Defender capabilities. USB Defender allows you to monitor and respond to USB mass storage devices that are attached to any servers or workstations that have a LEM Agent installed. This could range from simply monitoring device activity on your endpoints to detaching offending devices based on specific types of activity – an unauthorized user attaching a device to a critical server, or any device copying files from a predefined group of sensitive folders, for example.

    Thanks for your interest. Let us know if you have any other questions. You can also check out KB3207 on our Knowledge Base for more detailed information.

    Phil Morin
    Information Developer

  • Phil,

    Thanks much for your prompt and helpful response and the reference to the KB article. After looking over the article, I do have a few other questions:

    1. I appears that the agent is required for event log collection on domain controllers. Is this accurate? I ask because I'm aware of other products that don't have this requirement just for event log collection.
    2. With the agent deployed on laptops, there will obviously be periods where the agent can't report in because the laptop has been removed from the network. Is it fair to assume that reporting on these events will pickup from where it left off once communications with the laptop is re-established?
    3. Since Active Reponse is dependent on the agent, is it fair to assume that a copy of the Active Reponse definition/policy is cached locally in cases where, again, laptops have been removed from the network? That is, is Active Response still viable with a system on the go?
    4. I noticed that one of the possible Active Responses is disabling local accounts. Can Active Response be executed at will on a designated laptop (connected to the network with an agent) or does it have to be defined within a rule to function?
    5. Does the agent have to be updated with each patch or revision of LEM? If so, will the older agents continue to function while the newer agents are deployed?

    Thanks for your time answering these questions.



  • I appears that the agent is required for event log collection on domain controllers. Is this accurate? I ask because I'm aware of other products that don't have this requirement just for event log collection.



      That's correct. The benefit of the LEM Agent in this regard is that it collects, normalizes, and sends these log events in real time. That means your monitoring and its related active responses occur at network speeds. This also has a positive effect on bandwidth usage, given that events are sent as they come in rather than being sent in batches.



      With the agent deployed on laptops, there will obviously be periods where the agent can't report in because the laptop has been removed from the network. Is it fair to assume that reporting on these events will pickup from where it left off once communications with the laptop is re-established?



      That is correct. You will also see alerts both when the LEM Agent goes offline and comes back online. These are particularly useful for monitoring critical agents like domain controllers - not laptops, but they could go down for several other reasons. :)



      Since Active Reponse is dependent on the agent, is it fair to assume that a copy of the Active Reponse definition/policy is cached locally in cases where, again, laptops have been removed from the network? That is, is Active Response still viable with a system on the go?



      Not quite. Most of the Active Responses depend on connectivity with the LEM Manager. The one exception is the Detach USB Device action, which can be executed using the USB Defender Local Policy tool. You can read more about that one here: KB2689.



      I noticed that one of the possible Active Responses is disabling local accounts. Can Active Response be executed at will on a designated laptop (connected to the network with an agent) or does it have to be defined within a rule to function?



      Most Active Responses (including this one) are available on an ad hoc basis using the Respond menu, which appears throughout the LEM Console. You can use these responses in conjunction with a real time alert to expedite the process (i.e. take values from an alert to help fill out the form), or you can simply type in the values you need. Of course, rules can also be used to take action as you implied in your question.



      Does the agent have to be updated with each patch or revision of LEM? If so, will the older agents continue to function while the newer agents are deployed?



      Not all releases come with an update to the LEM Agent software. That said, we recommend updating your LEM Agents whenever an update is available - you can even automate the process from the LEM Manager. In addition to improving the LEM Agent software itself, LEM Agent updates will often include updates to their respective tools, which directly affects their ability to normalize the log data they're collecting.

      Thanks again.

      Phil

    1. To expand on your last point, you mention that deployment of the agents can be handled from the LEM Manager. Is this only for updating agents or can the LEM Manager be used for initial deployment as well?

      In looking over the LEM installation guide, I see the documented steps for single (local) installations and the Remote Agent installer. However, I see no mention of using LEM Manager for deployment. Is this a new feature?

      Also, the system requirements for the agent do not list Windows 7 or Windows Server 2008 R2 as supported platforms. Does the agent now support both these platforms in both 32-bit and 64-bit?

      Finally, going back to the agent deployment, can it leverage or even better, integrate with Active Directory to find the list of systems for deployment?

      Phil, thanks again for your time answering these questions. It's appreciated.

    2. To clarify what I said above, the LEM Manager can be configured to push automatic updates to connected LEM Agents. The initial deployment is handled outside of the LEM Console using either a local installer or the Remote Agent Installer. The latter can use either NetBIOS to "discover" available hosts or a text file that lists the hosts on which you want to install the LEM Agent software. For more information about the Remote Agent Installer, please see KB3222.

      With regard to operating systems, the most current list of supported systems can be found in either the KB linked above or the SolarWinds LEM QuickStart Guide. To answer your question, yes, we support both Windows 7 and Windows Server 2008 R2, 32- and 64-bit.

      Thanks again for all your questions. It's great to see this forum picking up steam.

      Phil

    3. Phil,

      Great information.



      With regard to operating systems, the most current list of supported systems can be found in either the KB linked above or the SolarWinds LEM QuickStart Guide. To answer your question, yes, we support both Windows 7 and Windows Server 2008 R2, 32- and 64-bit.



      Thanks for the clarification because the SolarWinds LEM Installation Guide (specifically, page 41) hasn't been updated with this information.

      In the knowledge base article for Remote Agent installer, there's a suggestion to run the Remote Agent installer at the WAN endpoint as opposed to executing it locally. Does this mean that the automatic update feature of the LEM Manager won't work for agents deployed across the WAN?

      Also, is it fair to assume that older versions of the agent will continue to work as newer agents are deployed? That is, are there any adverse effects to deploying the agent update over a period of time, say, a month instead of having to rush deployment in a couple of days?

      On average, how often are updates to the agent issued?

      Are there any plans to integrate LEM with Active Directory for the purpose of discovering computers and deploying the agent?

    4. The SolarWinds LEM Installation Guide is going to be phased out with the next release (coming in October), so that's why it hasn't been updated with the latest information.

      Regarding your additional questions about the LEM Agent:

      First, the Remote Agent Installer uses a completely different process than the remote update feature. The former uses Windows administrative shares (C$) to push the program to the designated hosts and then Windows APIs to create and start the service, while the latter uses the same connection the LEM Agent uses to transmit data to the LEM Manager. That said, we recommend running the Remote Agent Installer from the WAN endpoint purely as a matter of efficiency. You can run the Remote Agent Installer from wherever you choose, and it has no effect on whether remote updates from the LEM Manager are possible.

      Next, there usually isn't a problem with running an older version of the LEM Agent software, though this can vary from release to release. We'd recommend reading about each LEM Agent update as they come out and determine for yourself whether updating immediately is important to you (for example, if the newer version includes a feature you've been waiting for). At the same time, you should be able to determine whether the older LEM Agent versions will conflict with a newer version of the LEM Manager.

      Finally, I'll have to refer your last two questions to our product manager. :)

      Thanks again for all of your questions and feedback.

    5. FormerMember
      0 FormerMember in reply to phil3

      To answer the last two questions:

      >> On average, how often are updates to the agent issued?

      Generally, we minimize the impact/frequency of updates to agents as much as possible. With our next release, there is an agent update, and this will be the first time in about 18 months that we've updated the agent.

      The connectors/tools that connect your data sources to the agent can be updated separately and regularly from the appliance - but this does not involve a software update.

      >> Are there any plans to integrate LEM with Active Directory for the purpose of discovering computers and deploying the agent?

      What we find is that most customers use their own software distribution/patch deployment systems when they want more flexible agent deployment and better installation target discovery. You can run the agent installer in "silent" mode, loop it in to your existing discovery/install/update mechanism, and take our "discovery" out of the loop. That would also let you deploy to non-Windows platforms, if your software distribution software did as well.

      That said, we do have a roadmap item to better integrate the agent deployment into our Console, rather than being standalone. Pairing that with our Active Directory integration is a good idea, I'll make sure we update the feature request with that info.