Jump to content

WesleyNZ

Members
  • Content Count

    87
  • Joined

  • Last visited

  • Days Won

    11

WesleyNZ last won the day on November 27 2020

WesleyNZ had the most liked content!

Community Reputation

22 Excellent

My Information

  • Location
    NZ
  • Agent Count
    3000 - 4000 Agents

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Do a search on this forum for the role detection for TPM. It's likely the better way than to build it up by hand.
  2. It's actually not weird at all. It was easy to guess with your screenshots - thanks. You imported a monitor from a system (with a static ID in the import) that carries different sets of ID's (because the new one got generated as 515). Keep this in mind for any EDF importing stuff you do.
  3. your new server is bound to have a different extrafieldid (showing 529 above)
  4. in your top screenshot, click ignite and dig under there.
  5. Can you post a screenshot of what you got? By the sound it should be as easy as changing one > into a < (or visa versa)
  6. Not sure if theres an easier way, but what i'd do is: Exclude it from the existing monitor, then take a copy of that monitor and add on the config tab as part of the check, make it include the time-range during which it should be actively alerting. Now it will close tickets if the server is online again or if the end of the timewindow has been reached.
  7. Turns out it can be done from a script step too - this is probably the better way hehe.
  8. What did Connectwise say when you asked them that?
  9. Two different solutions for ya: 1) On the first agent, make the script set a location-edf (or client-edf). Then have a searchgroup filtered on whenever this location (or client) has the EDF ticked to start a script on the second agent (only). You could potentially mark the second agent with another EDF (or make it the probe/master and have it selected based on that). Or something non-scalable like specify the ID. 2) in the script you can just switch computers by changing the variable @computerid@ to the new ID. If you then also reload all variables in the script then most things like %co
  10. You will likely want to investigate more about Script States (and/or maybe script stats) instead. You likely don't want to create an EDF from a script.
  11. Have a look at the internal monitor called LT - Agent Out Dated. It calls 3 properties from the same place you've put them in; here's the answer from that: SELECT `value` FROM properties WHERE `name` = '_sysAgentVersionLinux'
  12. "{%-HKLM\SOFTWARE\ESET\ESET+Security\CurrentVersion\Info:InstallDir-%}ecls.exe" change program location to include quotes .. i dont know why but thats how i got ours working in the end.
  13. To answer your question; The SYSTEM context doesn't resolve usernames. To fix it - just use a hardcoded path like C:\Users\Public (or c:\programdata)
  14. To troubleshoot this you should hit the remote CommandPrompt button and then just explore the variable yourself - by typing: ECHO %username% Then in the response you can see what went wrong.
  15. It sounds like you want something checked regularly - when scheduling a script you can already schedule this regularly. So it sounds like what you should do is delete that external monitor (optional) and do everything from your script, and then schedule this to your hearts content.
×
×
  • Create New...