Still trying to figure out groups and searches

One of our current hold-ups is the problem with have with keeping certain machines *out* of groups.  There are two issues, first we have a client on-boarding process where we install agents, collect data and analyze the reports to look for issues (ie, server that has never been patched). Once we identify and resolve issues, we turn on the monitoring/alerting/patching/scripting.  We fell this is a prudent measure to take as we certainly wouldn't want to have a bunch of stuff blow up on the day we install our agents.

With Kaseya, it was a pretty simple process.  We always created our agents with a *do nothing* template that simply put the machine into the proper client group and audited the machine for system and patch information.  Once we had that we could determine if we needed to take any special remediation measures before we turned on the full management.

With Labtech, we have not found a way to get the machines into the system without having them automatically pulled into all of the groups that provide the monitoring, patching and scripting.  I contacted Kevin at Labtech and he is working on it.

The other issue will be solved by whatever the solution to the first problem is.  That issue is that at a few client sites there are machines that we deem as *do not touch* machines.  These would be machines like laboratory equipment machines, manufacturing automation machines, etc.  Essentially we monitor these machines and do remote remediation, but do not patch/script/reboot them as usual.  We need a way to flag these machines and keep them in special groups.

At this point I am not sure if it is the design of the Labtech groups/searches that is making this difficult, or just the fact that we are not yet aware of how to make it work.

DW

Post update non-issue

After we updated to 2010 we noticed that 9 of the 100 test servers were not showing on-line (but they were checking in and accessible).  We determined that the agent had not auto-updated from 0.835 to 30.917 on those machines.  I contacted support and they had me try a couple things then asked for me to submit the lterrors.txt file from one of the servers.  A few hours later Matt from support asked me to verify that at minimum, .NET 2.0 was installed on one of the affected servers.  I checked and found that in fact it was NOT installed.  I installed .NET 2.0 and forced the agent update.  Guess what, it updated!

So the lesson here is that when they say that .NET 2.0 is required, they mean that .NET 2.0 is required.

I am not sure, but I guess that the agent installer does not warn you, or require you to have .NET installed first.  That would be a nice dummy check for them to add to the installer.

DW

3rd training session

We have been fairly idle on our migration since our last training session.  Until we had more information on how the groups worked we were not ready to continue.  Now that we had training on the groups and templates we have the better part of the missing pieces.

Once again Robert was a fantastic trainer and we had a great Q&A as the last part of the training.  We hit him up with some pretty tough questions and he was able to get us great answers on everything.

We are continuing to work on how we will be pulling this all together over the next week and hope to be ready to get a 1000 or so workstations on as a first wave.

A couple things we are still trying to figure out are:

1. Auto-join for groups.  Seems simple enough and works well for the initial population, but if a machine falls out of the scope of the search it is not removed from the group.  Not a good example, but for instance if you had a search that populated a group based on the OS being Windows XP, then later upgrade the OS to Windows 7, the machine would remain in the Windows XP group AND be included in the Windows 7 group.

This has to be something that we are missing as I couldn't imagine this not working the way we think it should.

2. How to 'stage' new machines.  Currently when we on-board a new client we install agents on all workstations and server with certain templates applied that do nothing but collect system information and patch data.  We then run reports on this collected data, discuss it with the technical team and the customers for wrap up any details and then we apply our monitor/alert/patch templates.  We don't want to just pull the trigger on a network that probably hasn't had proper management since it was setup.  Nobody want to blindly release 130 patches on an un-patched server.

We thought we had figured out how we could bring machines into LabTech and have nothing done to them until we moved them into the proper group, but then realized that the searches which do all the work really didn't care if the machines were in a particular group or not.  The searches are going to populate the groups as that is exactly what they are designed for.  So we need to step back and rethink that strategy.

I am sure that we will have some other items.

DW

Upgrade to Labtech 3.0 / 2010

As I mentioned in an earlier post, we were not able to get the security roles defined exactly as I wanted.  Kevin from Labtech confirmed with development on Friday that the 3.0 release (now called 2010) would in fact have the ability to create the security classes as I needed.  We planned the upgrade for noon today.  At noon Kevin called and we got the process under way.  Within about 20 minutes the upgrade was complete and we started working on the construction of the security classes.  In another 30 minutes he had created and tested the 4 security classes that I needed.

I was impressed at the upgrade process.  It was about as simple as any upgrade I have ever seen.

DW

2nd training session

Yesterday we had our second training session with Robert from Labtech.  Unlike the first session where we had pretty much had already done all of the things he showed us, this session was all new territory.  We covered Monitoring and Scripting.  When I say "covered" think brain surgeon showing you how to do brain surgery.  These subjects are both very deep because they both very powerful and flexible.

We are still planning how we are going to structure the groups, monitor sets and scripts.  We have learned a lot in the years that we have been using Kaseya.  We are going to take that experience and apply it to this new tool and I feel that we are going to get incredible results.

So I hope that my fellow Labtech admins have a great Friday.  I am going fishing today!

DW

Support

I submitted a couple tickets this afternoon regarding y permissions issues.  Within about an hour both tickets had been responded to.  The first one I wasn't crazy about.  It confirmed to me that you had to give super-admin rights for a user to see the searches.  I don't think I understand exactly how those searches work or if it is even necessary for anyone to see them on a daily basis.

The other response was a little over simplified telling me to set permissions on the groups, etc, etc.  LOL!  I knew that...  Tell me what permissions to set.

A short time later I got a call from a support person named Kevin.  Very nice guy.  We worked on the issues for about 15 minutes and then said that he needed to reproduce them in his lab setup.

I feel confident that we'll get it resolved.  Our next training session in tomorrow and then on Monday.  That will probably go a long way in getting us up to speed.

DW

Permissions revisited

I have spent the better part of the day trying to get the permissions tweaked so that everyone has what they need.  I basically need 3-4 types of users.

1. Service coordinator - Simple access to see if machines are on-line. No interactive use.

2. Technician - general ability to work on machines through the machine interface or remote control.  They should also have the ability to view monitors.

3. Labtech "basic" admin? - Ability to create/edit monitor sets, groups, alerts, etc.  (no user LT administration).  Admin permissions to *almost* all groups (restrict access to internal company PC's and servers)

4. Super-admin.  - As the names implies, all access.

1, 2 and 4 seem to be ok.  I cannot seem to get #3 accomplished.  It appears that I need to give super-admin access to my RMM manager team to get some of this accomplished. 

I was told by support that to view the searches you need to have super-admin rights.  I must not understand the design intent of the searches if you need to be a super-admin to view them.  I might assume that the searches are solely for populating groups which would make sense then.

I am still waiting on a response to find out how to get #2 & #3 to see the monitors.

DW

Day 12 - 100 servers on line

It has been 12 days since I ran setup on our production LT server.  In that time my "Kaseya" guys have made a lot of progress deploying agents on clients servers.  Our plan is still to get one server at every client site on LT and have the network probe running and collecting data.  When we are finished with that and have our templates and monitors ready, the remaining servers and all the workstations should be a fairly easy deployment.

The progress that Joe and Jason have made is particularly impressive due to the fact that they have been doing these deployments in between their normal workload.  Only today did we finally put in a ticket for this so it was officially on the schedule.

Knocking on wood, we have not had a single agent installation failure or other issue so far.

Voice modem fun

Now that the server was moved to physical hardware I was able to work on the voice modem setup.  I ran the Voice Modem setup from the server and clicked through the informational screens.  When I ran the test, I entered a phone number to dial, clicked ok and then.... Nothing.

I tried a few things, re-read the wiki and searched the forums.  I submitted a ticket and got a response today that said "This is a known issue that has been reported to development and should be fixed in the next release".

Then I got another email stating that the ticket was being closed because my issue was resolved.

So I replied to the ticket asking if the "next" version meant v3.0 (next major release) and also asked for clarification as to the bug being with the testing of the voice modem or the operation of it entirely.

I hope that they just mean the testing part *or* they are talking about a dot release which might be out sooner.

First training session

Today was the first of our training sessions.  This session covered server installation and setup, some basic navigation stuff, groups, security and agent deployment options.  Based on the work we have already done we could have skipped this session, but it was good to see that what we had already done was validated.

Our trainer Robert was excellent.  (I give him an A) He was obviously very organized and prepared, he didn't miss a beat.  He crammed a lot of content into 2 hours.  I am sure that if we hadn't done all the work that we had, we would have been dazed by the time it was over.  One thing that he did was to make us the presenter of the GoToMeeting and have us record the session.  What a great idea!  It took the pressure off of worrying about taking detailed notes.

Based on what we saw, we feel our current deployment process is valid so we will continue as we were.

We are looking forward to our next session where we will be working with monitors.

K2 test server goes bye-bye

 So after a discussion with a peer yesterday about their continued K2 issues, it struck me that we still have a K2 test server spinning away in the lab.  This morning I told the techs that they can safely re-purpose this server for other lab purposes.

Backup/Secondary addresses for agent check in

One thing that we always ensured to do with Kaseya was to set the agent check-in addresses.  The first address was the hostname to our Kaseya server and the 2nd was the IP of the Kaseya server.  The second address was to enable the agent machine to check in if DNS was not available.  This helped us on more than one occasion, but it had an odd side effect.  If the Kaseya agent was checking in on the secondary address you could *not* remote control the PC.  The temporary solution was to change the check-in control to make the IP address the primary and then remember to switch it back.

One of my checklist items was to determine how we do this in Labtech.  Once again the Wiki is my friend.. Labtech Wiki page for secondary agent address

Setting it up appears to be quite simple.  Just specify the addresses separated with a pipe symbol "|".  I laughed when I read the line that said "labtech is limited to 10 backup addresses".  Really, only 10?  Has someone ever needed 10 backup addresses?

4 days later..

The week has gone by pretty quickly.  We have been steadily plugging away with our deployment and it is going well. 

One thing that we did this week was to move Labteh from Hyper-V to a physical server.  The move had nothing to do with performance, it was simply to allow us to *easily* connect a voice modem to the server.  Connecting a serial modem to a Hyper-V host and then having a guest OS access that modem seemed to be more work than it was worth.  I did make a feeble attempt to accomplish this, but using an open source com port emulation program didn't look like a supportable method.  I could see the support call now...

ME: "uh, our voice alerts are not working.  We are getting this odd error"
SUPPORT: "Hmm, sounds like a bad COM port.  Can you try moving it to another COM port?"
ME: "Sure, let me get back to you when I move our server to physical hardware"

So we'll just avoid that possibiliity....

With guidance from one of our crack backup team guys (Phil) I was able to move the server from Hyper-V to a Dell PE1950 in a couple hours.  Actually the "guidance" was in the form of harrasment about the fact that I shouldn't be doing the move and a member of the backup team should be (some days I feel like I am in a Union shop).  That ended with me losing a $5.00 bet to him over how a Broadcom driver would install.

Now that we moved that to physical hardware I will get around to making the voice modem work.

Joe and Jason have been plugging away and now how about 50 servers deployed.  The network probes are returning plenty of information and it looks like we will be able to easily deploy endpoints when we are ready.

We have our first training session on Monday.

Deployment to clients

Now that we could import clients from Connectwise, setup proper permissions and deploy tools we decided that we were far enough along for a few deployments to a small group of clients.  We picked three clients and went through our basic process of importing, initial agent installation, setting the server as master and network probe, etc.  It took us about 45 minutes to slowly walk through this on 3 clients (we were documenting as we went).  Everthing went very smoothly and within a few minutes one of the locations started to return network probe results.  I checked a couple hours later and it appears that all of the network probe information has been collected.

Our plan was to deploy more tomorrow if this was a success.  I guess we will be deploying...

Bill Morgan rocks!

I asked our rep (Gregg) if we could talk to someone prior to our training to help us with a few issues that we were struggling with.  He setup a 1 hour call for me with Bill Morgan.  I'd have to say that was one of the most productve hours I have ever had with a vendor.  I had already *baically* figured out the security, but Bill showed me how to manage the permissions using the "view permissions" and the "effective permissions" in the user setup.

Bill helped me with a number of other items, some of which I have commented on in other posts, but here are some others.

1. Connectwise Import returned nothing.  I had the integrator login access level set to 'Only creted by integrator' instead of 'All records'

2. The tool deployments were not working.  No matter which tool I tried to deploy (CCleaner for instance), I received a log entry of 'Could not transfer file /transfer/filename'.  Bill quickly identified the source of the issue which was a missing virtual directory in IIS called transfer.  He did tell me that it wasn't something I missed in the setup, but an issue that occured at times where the installer failed to create the directory.  It tool him 30 seconds to correct. it.

3. Explained to me how to change the display name of a machine.  In kaseya, we would frequently change the names of agents when they were oddball OEM machine names.  It was not obvious at all how to accomplish this in Labtech.  He showed me that by adding a 'Friendly Name' under the Info tab it would now be displayed properly.

There were a number of other items that I can't recall now, but the only thing he answered that I didn't want to hear was how techs change their passwords in Labtech.  The answer is that they don't, the administrator does.  He did throw in the words "for now", so I assume that this might be a future enhancement.

So Bill gets a virtual high five from me today.  Thanks Bill!

Started the ConnectWise integration

Last night I started the ConnectWise integration with Labtech.  I ran the installer and followed the instructions.  I was not prepared to complete all of the steps for ticket integration and such, but wanted to at least have the ability to import a client from ConnectWise.  Everything seems to be ok, but when I attempt to use the Import ConnectWise Client tool I only get an empty selection box of clients to import.  This in quite likely something I missed as I worked on it from about 1 AM until 2:30 AM.

More servers on line

I added 5 more of our internal servers to Labtech.  The agent installed quickly and I moved them into the proper location.

Attempting to install a MAC agent

We are having an issue installing a MAC agent from the service install web page.  We are getting "Page cannot be found" when clicking the link for the LabTechZ.dmg file.  It is there, so not sure what the issue is.  We'll ask support and see what they say.

Installing agents

Last night I spent more time working on agent deployment on machine in our office.  The network scanning works well once you figure out the proper sequence of making a machine a master, then network probe, then issuing a scan for hosts. 

Permissions

I spent about an hour working on the various levels of group permissions.  My goal was to restrict access to groups based on what security level or group the user is a member of.  This is necessary for when we allow internal IT staff at our client site to utilize our RMM tools.  It took a little time to figure it out, but I see that the security levels in Labtech are *very* granular and flexible.

System, Client and Group permission information is fairly well explained on their Wiki. Labtech permissions

Control center installs

Some of the techs went through the process of installing the control center.  Most went well, one failed and we needed to use a work around to install the Crystal Reports 2008 components.  After that, the control center installed just fine.  We found the solution for that one in the LabTech knowledgebase.

Rolling out control centers

I sent the instructions out to the entire technical staff to install the control center.  So far I haven't heard anything negative.

Don't walk away from your desk..

So I submit the support ticket go for some coffee.  I come back to my desk and see a voicemail from Labtech support!  I called back and left a message.

About 2 minutes later, Matt calls me back and helps me reesolve the issue.  Problem was that I was using the MSI file to install instead of the .EXE file.  Anyway, 5 minutes later the control center is installed and going on admin machine #1.

Issue installing control center

So the basic server install is complete and I attempt to install the control center on the first tech PC. I get the following message at what appears to be the end of the install.

There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor.

So I submitted a ticket to support.

Wow!

I just stumbled across something in the documentation under "Alert Actions" that could be seriously fantastic. This alert action is called "Voice". The description for this is:

Voice
This will use the phone line to call the Alert Contact and play a Text to Speech Alert Message if answered.

Note: Requires a Modem in the LabTech Server connected to a working phone line.

I know there are other ways to accomplish this, but this is awesome!

Making progress

So after a little more setup (following the wiki) and a few router changes the server is up!

Moving on

Support got the key/IP issue worked out without any issue and the installation finished in a couple minutes. I am going through the startup questions to finish up.

SSL

While I am waiting for the key to be reset I decided to get the SSL cert setup. Nothing special here. We use godaddy.com for SSL certs. I setup a new cert and had it installed about 15 minutes later.

I should mention that I am basically following the LabTech setup instructions from their Wiki which has been very easy to follow. Of course this is the 2nd time (first time was for demo server).

Support response

So by 1:20AM, support responds to confirm that the license key is in fact tied to an IP address. They tell me that if we are installing at the *same* IP, there shouldn't be any issue. If it is a different IP then we need to reset the key (which is what we are doing). I replied telling them what we are doing and ask to have the key reset.

First impression of support response = pretty good.

Issue #1

Small snag. I entered our license key in the installer and was told that it was not valid becuase it was being used on another IP. As it turns out, the demo key that we used for the trial install became our permanent key after we purchased. Even though our eval server is now gone, it must still be registered for the old server IP. I emailed our sales rep and support, I am sure it will be an easy fix.

Server setup

Based on our pre-purchase testing (and the documentation), we determined that the we should be fine utilizing one of our existing Hyper-V servers to host our LT server. For perspectve, our existing K server is a Dell PE2850 Quad-Xeon x2, 16GB RAM, RAID 10 array with 6x15K drives. For our initial LT server we will have a single (virtual) processor and 4GB RAM.

I created a new Windows 2003 server hosted on our Hyper-V server and ensured we were fully patched. I installed IIS and SMTP services and then ran windows updates again.

After taking care of a few other prerequisits, I downloaded the LT Server installer 2.5i and launched the install.

So far I have a couple hours of time invested (on and off).

I am going to have a few beers and read a little more documentation then revisit this tomorrow.

Getting started

This blog is meant to track our progress of moving from Kaseya to Labtech as our primary MSP/Network management package. In the coming weeks we hope to transition 3000+ workstations and servers from Kaseya. We will also be exploiting the tight (hopefully) integration between Labtech and our ConnectWise PSA.

Wish us luck...