Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


josh.ishak last won the day on May 1

josh.ishak had the most liked content!

Community Reputation

1 Neutral

My Information

  • Location
    New Jersey


    LT/NOC Admin

Recent Profile Visitors

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

  1. How long have you been using CWA12? Since release to Pilot What problems if any were encountered DURING the upgrade. How was it resolved? (Or is it still an issue?) None on a single server. I attempted on a tri-split and the installer tried to require Web service components on the Automation server, even though it recognized that the server was Automation-only. Issues was raised with support, recently elevated to a KI (I can't find it on the KI board now, but it's under 9643524/9576254). Needed to install the IIS roles required for CWA on the Automation server (not necessarily migrate services back to the Automation server) to work around it. What problems if any were encountered POST upgrade. How was is resolved? (Or is it still an issue?) If you don't run Solution Center updates after the upgrade, you're going to have issues with a handful of plugins. Remeber that you also need to update the Report Center to get it working in the right-click menu, AND you need to update all of your reports inside of the RC, as a large majority of them have changed for version 12. What is your feedback on the changes? What do you like best/worst? Definitely faster than 11. I quite enjoy the UI changes, despite still fumbling around them like I don't know what I'm doing anymore. That said, I spend most of my time in the database rather than the UI, and our use case is different than most. What feedback did you get from your other users/techs? "This patch goes a lot more smoothly than many of the past upgrades..." "This is a lot more intuitive than the old UI"
  2. LabTech used to have documentation up for moving from the 32-bit MySQL built in to LT10 and previous to 64-bit MySQL. This is essentially the same process, but they've found that, as of late, partners doing it on their own and encountering issues has been taking a huge toll on the Support team. They've since taken down the documentation and forced partners to contract the Consulting Services team to make sure it's done right. That said, there are some other consulting teams out there that are very familiar with LabTech and this process. It's something my team does for every one of our partners. I recommend that you go a little bit of "window shopping" for LT consulting teams - they all offer a wide variety of services (some offer one-off items, other require ongoing engagements).
  3. You may want to reach out to support. I'm not sure what would cause the table to just disappear. You wouldn't happen to have upgraded to 10.5 immediately before this taking place, would you have?
  4. It's actually the Database Agent service (LTAgent) that you're thinking of...The redirector service just negotiates the tunnels and redirectors (except for ScreenConnect). Check your LTAErrors (DB Agent Log) and LTASQLErrors (Log of all failed SQL queries) logs in Program Files\LabTech\Logs and your [servername].err log in your MySQL Database directory. Might give you a better idea of what's going on.
  5. It's also very dependent on the system itself. If there's win7x86 box that's missing a specific kb aritcle, any patching action that LT takes, including scanning the list of patches installed, will cause a huge spike in ram and cpu (usually 40-60% cpu and 1.4ish GB of RAM). I'd try what kyelnick suggested, but also take those results with a grain of salt as a fresh machine is very different from one in production already.
  6. Right now, there's no way to cut over to a MS SQL database. Based on current demand, LabTech has not felt that the effort put in to rewriting the application to work with MS SQL will be worth the return. You're right in saying that migrating the new database over to another server will just bring the mess over. To avoid doing this, you can install the LabTech server app on another server, migrate that Clients, Locations, Computers, Passwords, and Probes tables to the fresh DB, then cut over DNS to send the LabTech traffic to the new server. Some gotchas to note about this method: -You'll see errors when you try to import your locations and clients tables. Before you try to import, delete Client ID 1, Locations IDs 1 & 2 from the SQL script that Yog generates when you do the export. I generally get rid of Agent ID 1 in the computers SQL script as well, so that the LT server can continue to check in as Agent ID 1. -You ABSOLUTELY HAVE TO set the new server's "System Password" to the same as the old server. Otherwise your agents will be denied connection and will have to resignup. This'll create more of a mess than it's worth. -This will not bring over any Extra Data Field information, so all agents will have to (re)perform onboarding. To get this far, you'll have to redo your location service plans configurations as well. -This won't bring any scripts, groups, searches, or anything over, so now is a great time to audit everything you have in place. LabTech will only provide a migration key for about 20? days. They do not extend it, so get as much prep work in as you can before applying for that key.
  7. Are you sure it's LabTech that's sending you emails and not your PSA sending you emails about LabTech tickets? I'd go into the Dashboard / Config / System tab and make sure the Mail Setup segment is fully and correctly filled out.
  8. So that grabs the email address of the tech that kicked it off the script. To use that, you use the script step "send email" and place the variable in the to field of the email.
  9. To find out which search it is, you can run this query in your MySQL toolkit software (probably Yog) Select * from sensorchecks where sensid = '100'
  10. To approach the reaction first, LabTech generally executes under the System account, so if you're trying to have it launch a program, make sure the script you have runs with an IF user logged on so that it can pull the session, then go from there. As far as detecting machines that are not running lync, I would do a monitor like the following: Table to check: Processes Field to check: ComputerID Check Condition: Greater Than Result: 0 Identity Field: ComputerID Additional Condition: `ComputerID` not in (select `ComputerID` from processes where processes.`name` like '%Lync%') Obviously, you'll probably want to put other qualifiers in there somehow, because not every computer in the wild will have Lync installed, right? Maybe make a group populated by machines with Lync installed using an Auto-Join Search that looks at Related - Software Installed - Name. While this is a pretty decent proof of concept including more than just an internal monitor, it should be noted that if you're monitoring a critical process, you should be using a remote monitor, as those run right on the agent machine and don't require you update process inventory (which is 2 hours if it's the default). edit: added wildcards to sql statement...need more coffee.
  11. If you're trying to drive this externally, then you'll have to use SQL to kick off an insert of the client script into scheduledscripts with all of the paramters. If you want to know what that query would be, turn on SQLSpy and kick off the script manually, take note of what the LT server does, and copy that. Either that, or figure out that IDs of the Extra Data Fields you'll need to insert and insert them into the ExtraFieldData. You'll need to set the Location Password, Enable Onboarding, Server Service Plan, Workstation Service Plan, and all of the Patching information (not necessary, but will become so).
  12. Hello, The DR does not stand for removable device. there's a \DRX\ entry on every instance of the event, whether it's on a Hard Disk or Removable Storage --- this leads me to believe it's a location on the drive of some sort. The picture attached shows a machine one of my partners has with a bad block on its boot disk. Point is, it's HardDisk0\DR\0, and your edit would ignore that alert.
  13. If it's labeled NC, then someone accidentally applied it to a group it should not have been - the NC monitors out of box really only apply to the NC group. The monitors that are identical to this, but are on the 24x7/8x5 groups are labeled REG - X. The group of Reg monitors that LT provides check to make sure that their respective keys are empty --- I believe they're areas where viruses commonly hide out to execute, so LT gives us a way to detect this. If you look into the Additional Conditions of the monitors, there's actually a couple of exclusions that the stock monitor makes. I'd recommend copying their format and create exclusions there for Sophos.
  14. The biggest ones you'll need are: Client Locations Computers Computerconfig (I've had trouble in the past having not brought this over - it may not be relevant anymore though) Probeconfig (to keep your probes intact) Passwords (so you don't have to re-enter all of these) It's been a while since I've done one of these, so I'm a little fuzzy on whether or not there were any others. Martyn would know, he and I reviewed this recently. Some things to note: -You'll need to set your service plans on your locations again ---- this will not come across since you're not bringing over the Extra Data Field information. -All agents will need to be onboarded again, so make sure you make any edits to the role detection scripts and the product key scripts so that they don't blow up your newly cleaned db with tickets. -You can bring groups over by pulling from the Mastegroups table, but I don't recommend that --- rebuild your groups manually so you can thresh out stuff you don't use anymore. Every time I've done this style of migration, it was meant to really audit every piece of automation I had made over the years.
  15. There's not really a good way to do this. I've resorted to making two monitors - one stock one that only applies to servers, and one copy for workstations that has the add'l condition of Eventlogs.message like '%harddisk0%' This isn't the greatest solution - it only looks at the HDD that windows mounts as the boot drive. If you have any other hard disks, it won't trigger an alert on events for those extra drives. Right now, most of my partners don't have any PCs in the wild with more than one drive, so it suffices for them.
  • Create New...