Gotchas
- You’re going to be overwhelmed. It’s a beast with a lot of power, and a shitty UI!
- Give the Labtech server power, and if you can, SSDs. At least double the RAM LT recommends. It’ll run wicked fast on the client end.
- When deploying agents, don’t rely on Labtech to install them over the network, it so rarely worked for us. Do it with GPO or manually and save the hassle waiting for it to fail over and over.
- Don’t name your client sites “main”. Go into your PSA or whatever CRM you have, and give your clients locations good names, then mimic that.
- If you know nothing about databases or SQL, get someone learning it, you’ll see random SQL strings that you want to be able to make sense of.
- Ignite monitoring is going to be loud and noisy, prepare to tweak it. Don’t just disable monitors because they are annoying, figure them out and get them tuned.
- Keep on top of your software white and blacklisting. It’ll be a hassle in the beginning to whitelist all your clients, but be prepared to make it a weekly ticket to go through the gray-listed stuff, because if you let it get behind it’s a nightmare to catch up.
- If you are syncing to connectwise, be prepared to be annoyed by contact syncing, that’s all I can say. I would recommend you use Labtechs AD plugin to grab end users from AD, and populate LT and CW with those. Making AD the master DB essentially.
- Once the probe is running, actually go through those network devices and give them a good name. So many of our network devices had default hostnames, so we just started our naming scheme in labtech, and we change the network devices to match that (as we stumble upon them)
- Don’t delete agents, make a company called Z_RecycleBin, and put them in there. If they have been in there for greater than 6 months, then delete them.
- Prefix ANYTHING you build in Labtech with yourcompanyname. Groups, folders, scripts, whatever. It’ll help you weed through what’s built in, and what you’ve built.
Beyond that, just make sure you grasp these concepts
- Groups are made up of agents. Agents can be in multiple groups.
- Groups are (usually) auto populated by saved searches.
- Searches look for things in the database that are true in order to find results, in example; if a location has the “patching” set for Thursdays on Desktops, all agents in that location will match a search looking for them, and thus it puts those agents in a group which has a template to patch on Thursdays.
- Templates are applied to groups. Templates can be thought of as a “policy” for the agents to live by. It tells the agent ALL SORTS of information and rules on how to behave and look. Since an agent can be a part of multiple groups, that means it can have multiple templates (AKA Policies), remember you don’t want conflicting settings like on group policies or inheritance and over riding gets messy.
- Groups also have Monitors assigned to them. This is how Labtech is able to monitor only exchange servers for exchange specific things. Search for role = Exchange, put in the “Exchange servers” group, on that group apply Exchange related monitors and even scripts.
- Scripts are run on Agents, in the context of the agent. The variable %computername% in a script will always return the computer name of the agent. Press F2! it lists them all.
- Extra Data Fields are the magic of Labtech scripting. It’s even how Labtech builds a lot of their automation (The entire “ignite” tab is extra data fields). Make a few test ones and play around.
- Monitors, there is 2 kinds (well more, but these are the confusing ones) Internal Monitors are “Database Monitors”, they peruse the database tables (which the agents fills with information on certain cycles), and example of an Internal Monitor is “Blacklisted Software Installed”. The Agent isn’t aware of every peice of blacklisted software, but the database is. On the other hand, Remote Monitors are monitors running on the agent itself, these are more real time like CPU usage or RAM usage or a service going down.
- Dataviews are glorious. you can right click a computer, location, client, or group and data a ton of information in seconds. If you’re feeling strong in SQL, find the hack to enable your own dataview creator. Note: By default you can Edit and Save dataviews with a new name, after you’ve added/removed columns. Another thing, right click in your dataviews and you can run a script or command against the results.
Helpers
- RIGHT CLICK ALL THE THINGS and be pleasantly surprised when you DO and DON’T find something.
- Commands can be thought of as labtech “functions” or “very specific scripts” (they are not calling scripts though). They are essentially simplistic things that require almost no input or logic, like “reboot” or “Install Patches”.
- https://docs.labtechsoftware.com is a place you’ll get very familiar with.
- http://www.labtechgeek.com/forum/index.php is fantastic, and is run by Greg Buerk one of the devs of labtech, super knowledgable.
- Once you get into it more and want more, check out plugins from squidwerks and labtechgeek.
- Learn and understand the solutions center.
- Once you figure all that out, get Patching going, get SNMP going, get the AD Domains Plugin going, get the virtualization plugin going (VMware and HyperV), build your own commands.
Wow, what a brain dump… Hopefully some of it helps. Last peice of advice:
- Be prepared to designate members of your team to sections of labtech. One or two guys can NOT run and understand it all, unless it’s 50% of their paid hours. One guy is patching and scritping, one is SNMP and network probes, one is virtualization and AD managers managers, one is monitoring.