Jump to content

Moving to Automate - Thoughts and Pitfalls?

Recommended Posts

Hi All, 

We're in the process of migrating our 14,000 endpoints from GFI/LogicNow/SolarWinds RMM over to Automate and wanted to shout out to all of you who are currently running the product of anything you think we should be aware of from a nice blank install of Automate? 

I'm curious to hear any "if I could go back" stories or if you would do anything differently based on the knowledge you have now since installing the product? 

We are in very early implementation with only our internal devices on the platform and are working with our Automate consultant on a few things (we've just turned on Ignite and damn that thing is noisy, especially for workstations). 

Interested in any thoughts, stories and ideas you guys have, we're very new to the product so apologies if I come across a bit stupid at times because of that!

Edited by Flobberknock

Share this post

Link to post
Share on other sites

I know from our Own experience with about 7k endpoints make sure you know what in regards to event logs your bringing in, and how many days of them your keeping in the database as originally we went with 30 days and that was just incredibly unruly and made our database and performance a small nightmare. even at 4 days sometimes we have issues. that is one thing i would definitely discuss with them before you go to far.

Share this post

Link to post
Share on other sites

I'm grabbing a quick lunch, just wanted to throw down some quick thoughts.


  • Automate is a difficult system to use when you don't know how to use it. Make sure you (or your automate admin) has at least a base understanding of SQL, and make sure you've explored these different topics and thought about how you can utilize them together for your specific setup:
    • Advanced Searches & Groups
      • Searches to add computers to different groups (NO REBOOT Workstations, Production Workstations, Bitlocker Enabled Workstations, etc)
    • Monitors
      • Trapping for key application crashes at certain clients - utilizing groups to define which workstations are actually monitored
    • Scripts
      • Custom built scripts - Dell Command Update automation utility, record Bitlocker recovery key and store in Labtech EDF for that computer (saved my ass a few times), custom computer deployment script
    • Roles
      • SQL Servers have monitors that are specific to SQL, etc.
  • Set up your patch groups correctly the first time, or you'll spend time cleaning up mistakes you made the first time around. This also applies to setting up groups, searches, automating scripts, etc.
    • How do you trap for workstations that have missed patch windows multiple times in a row?
    • How do you trap for workstations that have failed patches multiple times in a row?
    • Do you want to run a script that creates a powershell pop-up before that workstation is due for its patch window?
    • Do you understand how patch windows work, how reboot windows work, etc. This is important for troubleshooting the patch manager
  • Utilize your own EDF's (Extra Data Fields) to help you define custom groups or custom settings, and help scripts make decisions.
    • For example, I have a new workstation set-up script that we built from scratch. Our technicians check off the software they want installed, have the option to fill in certain customizable properties, and then a monitor catches the "Deploy Mode Enabled" checkbox and kicks the script off. The script will deploy software according to the EDF's checked on the computer's "Deployment Script" Extra Data Field tab.


Wrapping up here, I can add more later once I get an opportunity. I would recommend doing something like building your own deployment script (I can share mine once I have some time to sanitize it) in order to learn the capabilities of Labtech. It's quite extensive when you know how to use it, but it can feel restrictive if you aren't really familiar with all the different moving parts & features. A great example is that in my DCU update script, I actually have the labtech script scan the .XML file that is generated during the update check to see if a reboot will be required to complete the update. It has a lot of capabilities, the trouble is making sure you have the time to figure all them out and make sure you're using them efficiently.

Sorry if this was a bit scatterbrained, I didn't go back to organize or edit, just a bit of a brain-dump.


Thanks, and good luck! Feel free to ping me with any questions.


Share this post

Link to post
Share on other sites

We migrated ~2500 endpoints from Kaseya to Automate over the start of the year going into mid-springtime. I have a few thoughts, which may or may not match up with anyone else's, so... grain of salt, I guess.

  • Make the heck sure that you have consultation hours banked with ConnectWise. You will have questions, you want a consultant available who can get you answers. We did this and it's 95% of the reason why we have a functional system now. (I mean, I'm good but adjusting to that-which-was-LabTech was a thing and a half.)
  • Be prepared to disable all kinds of built-in monitoring systems. Most of them are so, so noisy. Also be prepared to dig through the archives of this here forum in search of how to edit the built-in searches and monitors and scripts to deal with things like, oh, Automate building semi-bespoke disk space monitors for attached USB drives. Ahem.
  • Learn the EDF (custom fields)/search/group triumverate. It is where the bulk of your successful automation efforts will take place, and it's ridiculously powerful and good. When asked, I reply that it's my favorite thing about having done the migration. (Second-favorite? Control, formerly-known-as-ScreenConnect.)
  • Sean, above, makes a case for having some SQL knowledge. Which is good, but if you're cloud-hosted by CW themselves you'll have... limited access to the actual SQL server. We have generally made do without getting into the SQL weeds. Could we be doing better if we were SQL gurus? I don't doubt it. But don't feel like you're going to be hamstrung without it.
  • User permissions are super duper weird. In order to grant an account the ability to change an endpoint's location we had to give their class access to... I think it was one of the Reporting tickyboxes? Whatever, it was super counter-intuitive. Other than the rickety agent-deployment process itself, permissions are the most frustrating thing in Automate.
  • Think through every possible outcome when building your scripts, and leave breadcrumbs (log entries with shell command results, mostly) for "well this shouldn't have happened" situations. Later!You will thank Today!You when troubleshooting why your script didn't do what you thought it would do.
  • Scripts have permissions. Make sure that user classes that don't need access to the more dangerous scripts (like ones that perform queries against the live Automate database) aren't available to your rank-and-file techs, let alone any high-end clients you may decide to allow any kind of Automate access.

That'll do for now, I suppose.

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...