Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

Community Reputation

0 Neutral

My Information

  • Agent Count

Recent Profile Visitors

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

  1. If I were doing this, I'd probably create an EDF checkbox and have both groups populate based on whether that EDF was checked or not.
  2. Editing originals monitors/scripts/etc VS. Making copies that are then edited There seems to me to be a downside to both ways, but one can be more problematic than the other. As Matthew1986 mentioned, customized originals that are overwritten during an update lose their local changes, and that could "break" your processes. Depending on what your tweaks do, that could be very bad. You'd have to re-customize changed objects as soon as possible every time you update a solution. On the other hand if you customize copies of the monitors/scripts and then CW updates the originals, your working copy will still function (in most cases). You might be missing out on new features or streamlined solutions, but things should still work as you designed. You'll just have to manually review the changes to the originals to see if you want them in your custom object, which can be done whenever you have time. I think this is why they say that editing copies is best practice, but if I'm wrong I hope someone will correct me.
  3. 1. EDFs are created in the System Dashboard. They are not applied to specific agents or agent types so all agents will have the EDF you create, but it doesn't need to have meaning for every agent. Simply ignore that EDF on your workstation agents. ***Note, you might want to give your new EDF a default value that is your most commonly used threshold. That way you only have to change the value of the EDF on servers with a threshold different than your default. CWA documentation on creating EDFs and their default values: https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/060/140/020 2. Yes. In your script use the "ExtraData Get Value" function. It will let you assign the value of your EDF to a variable you can then use in your script. CWA docs on the Database Functions: https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/070/240/050/040/020/040 3. The CWA docs will guide you through all those steps, but depending on which servers you want it to run on, CWA may already have the groups you need (such as Groups\Agent Types\Windows Servers). CWA docs on searches, using and saving: https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/070/250/010 CWA docs on creating groups: https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/070/090/020 CWA docs on scheduling scripts: https://docs.connectwise.com/ConnectWise_Automate/ConnectWise_Automate_Documentation/070/240/030
  4. Just sharing my experience. I've had several support tickets about it with CWA support (one still open) and discussions with our sales rep. The last tech that worked the issue had an unofficial fix that addressed part of the problem I described (it was a query that would remove the mismatched standards), but not all of it, so he wasn't able to get our system fixed. He took lots of screenshots and notes, but that was 7/12/18. I haven't seen any progress yet, even after asking the sales rep to check on it for us . Just the occasional automated email saying someone will contact me soon. I'm not saying that all agents, workstations and servers alike, get the same score. I'm saying they are given scores/checks they shouldn't. If you look at the results of the Standards & Health checks for any agent, and if you have the same problem I do, then you will see that under standards both the workstation and server standards are being evaluated. Since those standards are also tied to health check scores, all agents have a score for both the "Workstation Standard" and the "Server Standard".
  5. Standards and Health is broken and no word on when/if they will fix it. All standards and health checks get evaluated globally, so workstations are scored for server standards/checks and vice versa. Also, in our case, when we did make customizations to the tool, like editing default standards/checks and/or adding our own, those changes were overwritten when the solution was updated from the Solution Center.
  6. Yes, by using a script and the ExtraData Set Value function. If you want the EDF to contain only the name of the agent's reboot group, then set the value of that function to the group name and run your script on the group.
  7. The remote monitors for disk space are created by a script: Scripts\_System Automation\Agent Maintenance\Agent Monitor Creation - Disk* That script is called by 2 other scripts: Scripts\_System Automation\Agent Maintenance\Agent Monitor Creation* called by Scripts\_System Automation\Agent Maintenance\Agent Maintenance - Contract* also called by Scripts\_System Automation\Onboarding\Onboarding Scripts\Maintenance\Agent\Agent Monitors - Disk - Remove and Rebuild
  8. Similar issue here. Installed v12.0.361 on Friday night (updated from v12 p5). Super Admins don't get these errors, but everyone else gets it for each Computer Management window. If the tech opens additional Computer Management screens within the same window, then there is no error. The Computer Management screen still seems to load properly. I contact support and was told:
  9. I'm not sure why the OP needs it this way, but I once helped an LT user that had an Exchange server agent where the OS was being reported as only "x64". This made the server list in the navigation tree as a workstation (beneath the servers), and that was driving the user crazy. He didn't want to take the time to troubleshoot why the agent wasn't reporting the OS name correctly, so that was my dirty fix.
  10. As far as I know, yes. If OS like '%Server%', it's a server.
  11. This isn't an ideal solution, but it has worked for me in the past. Create a script that will set the OS to what you want it to be and then run it on the agent every 30 minutes or so. SQL EXECUTE UPDATE `labtech`.`computers` SET `OS`='Mac OS X Server 10.11.6 (Darwin)' WHERE `ComputerID`=@computerid@
  12. I have a system property that records the highest ID number of all the current agents. Then once a week I run a script that finds all agents with an ID higher that the system property. It lists all those agents in a CSV file that is stored on the server, and then creates a ticket and attaches the spreadsheet. Of course, it also updates that system property before it stops.
  13. Most definitely, I will. Probably going to end up doing a migration then upgrade, so I can get the system running on Windows Server 2016. It'll be a learning experience, I'm sure. The previous LT admin has made edits to some default LT scripts, and didn't document anything, of course. I'm worrying a lot about the upgrade overwriting some of those scripts. I really wish the old marketplace granularity was still in place, so I could check each script for local changes without having to click through each solution. Anyway, thanks so very much for your input.
  14. I've asked the some of the same questions. I'm eager to see if you get meaningful responses.
  15. I'm in the same boat. I hope you get more response to your post than I did. I'll be watching with great anticipation.
  • Create New...