SNMP traps

We have been through a few RC builds of 2010 and we seem to be getting closer to getting the SNMP traps working.  The last build fixed some things, but didn't fully resolve the issues.  I worked with Kevin Davis on the SNMP for a while and he sent logs to development.  It sounds like they identified and corrected another issue so we will have another crack at it soon!

DW

Connectwise ticket integration

Last week I worked on getting the CW ticketing integration finished.  I had already setup most of what was needed when I setup the ConnectWise Plug-in to do the client imports, but there were still a few items to finish up.

My first couple tests were not successful so I submitted a ticket explaining how I tested and that no ticket had been created in CW.  Support asked for some additional information and said that it looked fine so they wanted to schedule a time to get on our system to investigate.  The next day I tried to import another client and couldn't locate them in the list to import.  In the past when that has happened, it was caused by not having the customer type set to match our plug-in filter setting and that was the case with this one.  Seeing that made me think that my ticketing issue could be related as my test was on an alert for our test company, not an actual client.  I tried creating a ticket from a 'real' alert and the ticket was created in CW instantly!

So, my take away on this is that the customer type filter setting in the plug-in is for more than just importing.  It seems to control the scope of what the plug-in will see which now makes perfect sense.

DW

Scripts and permissions

During a quick training session with a couple techs I found out that they could not execute/schedule scripts.  I checked permissions on the users, groups, clients, etc, but couldn't find anything that would allow them to execute a script.  I sent it to LT support and they requested a screenshot of the user permissions. 

About an hour later I got a call from Kevin to review this.  He found the issue in the persissions for the individual scripts.  The one place I didn't look was *in* the script.  Each script has edit and execute permissions and since we had made some significant changes/additions to the security groups structure, the groups were not in the scripts.

Now I just need to either use one of the security roles that already existed (and add it to the techs) or add the tech security roles to the scripts.  I haven't decided which way to go yet.

So remember that the security for each script is *in* the script.  The ability to execute/schedule scripts (at all) is in the user/group security.

DW

Almost ready to start pulling Kaseya agents

We have a few things left before we can start pulling Kaseya agents (from workstations), but I think we are close.  Some of the items are:

1. Finish Connectwise ticket integration
2. Tweak a few monitors & scheduled scripts
3. Additional tech training
4. Get SNMP traps working.
5. Get a document to our clients describing the new way of submitting a ticket through the mgmt icon in the tray.

Hopefully we will be able to start the Kaseya removal by Friday afternoon.

DW

SNMP Continued

I worked with LT on the SNMP issue for about an hour, but was not able to get it resolved.  At this point I am not sure if it is our testing methodology or LT.  LT has been making changes to the SNMP Trap monitoring, so this could just be some side-effects of being on a release candidate.

For anyone that is interested, there is a good tool out there for sending SNMP traps.  It is called TrapGen and is a free download from NCT.
http://www.ncomtech.com/trapgen.html

To send a trap to a trap receiver, you simply use the command TRAPGEN -D xxx.xxx.xxx.xxx .

It will send a static SNMP trap to the device and is very useful for testing.  You can override the static trap info by using additional command line options.

I also did some packet captures to identify the SNMP traffic to ensure that it was being formatted correctly. 

DW

SNMP Traps - Stuck

I thought I was home free on the SNMP Traps, but it turns out that I might have been a little too optimistic.  The initial success of having alerts when an SNMP trap was sent turned out to be less than I had hoped.  After I got those first few alerts I thought we were home free.  I put that aside for a few days and revisited it last night.  What I now realize is that all it is telling me is that the probe received a trap and that is it except for a number that appears to be a sequential number of some sort (serialized??).

To make matters worse, I was getting a pile of these alerts via email, so I decided to remove the SNMP setting for now, but I am still getting alert emails.

I will grant the fact that I am on a release candidate of LT2010, so the possibility of a bug is certainly a reality.  I am waiting to talk to LT support about it some more.

DW

Major problem - quick fix

Today we instructed techs to use LabTech for the portion of the client base that we have dual installed (LT/K).  The first issue we ran into is that the remote control wasn't working at many locations.  We figured out pretty quickly that the issue was caused by the fact that we did not configure the clients routers to allow TCP/70 out (which is the default redirector port for LT).  At first we thought that we would need to touch all of the routers that were tightly locked down (most of our clients are configured this way), but then we realized that we already have all of those routers configured to allow TCP/5721 out because that is what we needed for Kaseya.

I changed the configuration in LabTech to do the redirection connections on 5721, changed the router in the data center and BAM, all the remote control sessions would now work.  Zero time spent changing routers :-)

So, for anyone making the switch from K to LT, you might want to consider this if you have many clients that have locked down routers.  It saved us a couple days of time.

DW

SNMP Traps - I should have RTFW

So I setup a time to work with Kevin from Labtech on the SNMP trap thing.  Given my struggles with it in the past I chose to do nothing with it until I spoke to Kevin.  I got on the phone with Kevin and he walked me through adding an entry under the SNMP traps section of a machine configured as a probe.  For the test, we created an entry that would accept ANY OID from ANY host matching ANYTHING.  Kevin explained that a currect "limitation" is that the alert you get is limited to an email to the alert contact for that location.

Then we were done with the seteup.

I was a little shocked that it was that simple.  I really should have RTFW on SNMP traps.  It is a single page and there is a good reason why it is that short. Labtech SNMP traps WIKI page

I let Kevin off the phone and did some testing and it worked! 

DW

SNMP Traps

Now that we have the big rocks out of the way (at least we think we do), we need to concentrate on some of the finer points.  One thing that we always struggled with Kaseya was effective SNMP monitoring and alerting.  In all fairness I think it could have worked better, but it was a real pain and I always seemed to get inconsistent results.  Of course the Kaseya support was completely unable to assist me on this stuff.

I have already done some basics with Labtech and the SNMP functionality, but the one piece that I am anxious to get going is the ability of a Labtech endpoint to act as an SNMP trap receiver.  We have a special application that requires us to be able to receive traps from an SNMP enabled device as opposed to querying OID values and checking them.  This is purely catching the traps as they are sent and processing them.

During my initial discussions with Labtech we discussed this with Gregg Lalle and Bill Morgan.  At first they said "oh, sure no problem monitoring SNMP", I then clarified about the traps and Bill said he had to check on that.  By the end of the conversation Bill had checked with someone and told me that it absolutely could be done.  Nice!

Now I just have to figure it out.  I sent a request to Kevin for help on this, he is probably ready to kill me :-)

DW

Goal for the week

Our goal is to have at least 1000 of our managed workstations moved by this Friday.  Joe and Jason have their work cut out for them!

Group issue is resolved!

Kevin from Labtech emailed me yesterday morning that he had verified that he had a workable solution for our on-boarding and do-not-touch groups.  We setup a 1 hour meeting for noon to review it with him.  The way we are accomplishing the on-boarding is to create a custom field at the client level called 'on-boarding'.  When this box is checked, all machines that are under that client will be added to the group 'on-boarding'.  The on-boarding group is a master group which will remove machines from all other groups (except other master groups) and prevent it from being added to any others.  We simply ensure that there are no active scripts/hotfixes/alarms etc in the on-boarding group and everything is good.

The do-not-touch is pretty much the same where we have a group of the same name and a customer field (at the machine level) to do the same thing. 

One thing that this requires is that you do not make any other master groups as a machine *can* be a member of more than one master group. 

Two things that I really like about this solution is that it did not require us to modify every search in the system to *exclude* the on-boarding or DNT machines and it is ust a single checkbox (so very little in manual interaction). 

We feel that the solution is going to work perfectly for us.

Thanks to Kevin from Labtech!