Jump to content

jyhirth

Members
  • Content Count

    37
  • Joined

  • Last visited

Community Reputation

1 Neutral

My Information

  • Agent Count
    Less than 100

Recent Profile Visitors

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

  1. Still works on 2020.7 Great trick, thank you @myoung!
  2. Nope. It's been a couple years and Automate versions since I last tried tho.
  3. Vitaliy, Can we get an update on this? What are Veeam's plans with respect to Veeam Windows Agent 2.0 support for the LabTech Veeam Endpoint backup plugin?
  4. Vitaliy, We've discovered what we believe is a bug in the latest release of the plugin that prevents the backup job failed monitor from detecting failed backup jobs. We've opened ticket 01989228 with your support team. On our system the remote monitor for backup jobs ending in error is checking the Application Log for event ID 191 with source of Veeam LT and event type error. That is wrong, and the monitor doesn't fail when the job does. The backup job failed monitor should be checking the Veeam Backup log (*) for event ID 190 with source of Veeam MP and event type error. Basically, it should be the same as the Backup Job Warned monitor with the exception of the event type. It's possible that the bug is only on my system due to someone messing with the monitor, or a failed update process when we last updated the plugin last week. My apologies if this is so. .
  5. Greg, We've been running this plugin for years, been working great. I think it's one of the most under-appreciated plugins. Recently, I've been wishing it was possible to set the Computer field in a rule to one of the regex group matches. For us, the value we're looking for is in the subject. So if it was possible to select in the 'Computer' drop down, for instance, %emailsubjectN% or something like that and have it pull the value from the regex match, that would be very useful. I'd imagine it might be useful for the client dropdown as well. Thanks! JH
  6. I grabbed the download link and instructions from someone on the slack channel.
  7. Still going strong here. 0 additional agents with the problem over night. Seems like this might be licked. So that begs the next few questions: What is the effect of setting self protection = minimal? What exactly is turned off by this on the WR side? What does this make the endpoint vulnerable to that it would not otherwise be?
  8. Since my last post we've had 1 agent with the issue. So the self protection: minimal is not 100% effective. Still, just 1 is a major improvement.
  9. Since making the change to Webroot (self protection changed to minimal) about 30 hours ago we have had no agents with the issue. We were previously seeing about 15-20 a day.
  10. I haven't really modified your script much other than to add a check in the beginning for pending reboot, and then I exit the script if there is one since it will fail anyway if its pending reboot. I did, however, write another script that is capable of automating the Windows Update Diagnostic toolkit. On systems where the rollup updates fail I've found that the diag t-shooter can fix WUA and then the rollups succeed. The t-shooter is available here: https://support.microsoft.com/en-us/kb/2509997, look under Method 1. And I was able to automate the t-shooter using the info at this link: http://superuser.com/questions/871822/creating-an-answer-file-for-windowsupdatediagnostic-diagcab-in-eclipse-wtp The result is the attached script. I've been running it manually on troubled systems. If you want to schedule I'd recommend you add some sanity checks, the code here is pretty raw. The attached zip has the script as well as the .7z file it references that contains the diag t-shooter itself. I still have some ideas for improving your script. I found a way to do a process check loop so we can wait for wusa to finish before moving on. I also found a way to schedule a reboot for systems that need it. But I've got bugs in both so I'm not ready to share publicly yet. Hope this helps ... JH WUA_diag.zip
  11. I think you're referring to the script sleep function. I did put that in but as you point out the time to run varies anyway so its not that helpful. I'm waiting 5 minutes. I'll post back when I'm happy with my changes, as of now I haven't done much to improve upon it any, still trying though. Have you run into problems with agents not actually coming up in version level after the script runs? I'm seeing that about 20% of the time. The script runs, appears to be successful, we reboot. Ver # is still old. Something failed and wasn't caught in the shellresult. JH
  12. OK, I got that done by doing a registry check, seems to work. One more issue: I notice that the script issues the shell commands and just moves on. But the actual install process takes some time to run on the endpoint. Is there any way to get it to wait till the installer is finished before moving on?
  13. I modified your script so that it does a Resend Hardware Inventory as the last command. This updates the reboot flag. One issue I'm having is that the WUA version doesn't update until after the reboot. So if you schedule this script on a group to run periodically it will run over and over again until the reboot occurs. Which seems messy ... I'd like to build in some logic at the beginning of the script that exits if the reboot needed flag is set to prevent the rerunning of the script but I'm struggling with how to do that. There is a search built in to LT that looks for flags=1024 but I can't figure out, other than via raw sql, how to get that in the script. These registry keys might help, going to try that next.
×
×
  • Create New...