Wednesday, March 2, 2011
Labtech LabVNC slow - fix
At some point in the last few months we have seen a signifcant performance issue with LabVNC. I spoke to support about it and they are aware of it and say that it will be resolved in a build soon. They gave me a work around that is actually quite easy.
Monday, August 9, 2010
Scripting a 'Suspend Alarms' Function
In Kaseya we were used to a very handy feature in the monitoring system called Suspend Alarms. We used this extensively during maintenance periods and one-off server reboots. As you can guess, this would suspend the generation of any alarms during our maintenance.
I found that in LabTech there wasn't a similar function like we were used to in Kaseya. In LabTech you opened the machine and checked the 'Disable Alerting' checbox under the info tab. This would certainly disable alerting, but our concern was that it could accidentally remain checked if the tech forgot to uncheck it. Also, it really wasn't a solution to our maintenance window issue where we need to suspend alarms on large numbers of servers at one time.
The solution was to write a script to enable and disable the Disable Alerting. Since there wasn't any specific function in the scripting to set this field, it required using a Run SQL script command.
update agentcomputerdata set NoAlerts = 1 where ComputerID='@computerid@'
Pretty simple, but then we wanted to ensure that it was set back to 0 some time later so my solution was to add two more steps to the script. Step 2 was to put the script to sleep for a while, say 30 minutes then run another sql command to set NoAlerts back to zero (same sql statement with a 0).
I was pretty happy with that, but then Bill Morgan from LabTech suggested that we just add an enable and disable script to our maintenance script groups and then we wouldn't need to treat it as a separate item. I think we might have come to that conclusion on our own as we decided *where* we would schedule this script, but it was another one of those ah-ha moments.
The best part of this is that it will cure one of our most common mistakes, rebooting a server without first suspending alarms. Yes, about 50% of the time when a tech schedules a reboot (outside of or normal maintenance window), they forgot to suspend the alarms in Kaseya. Because rebooting is a script AND disabling of alarms is a script, why not just combine the steps? By combining these two scripts we will no longer even need to think about suspension of alarms.
DW
I found that in LabTech there wasn't a similar function like we were used to in Kaseya. In LabTech you opened the machine and checked the 'Disable Alerting' checbox under the info tab. This would certainly disable alerting, but our concern was that it could accidentally remain checked if the tech forgot to uncheck it. Also, it really wasn't a solution to our maintenance window issue where we need to suspend alarms on large numbers of servers at one time.
The solution was to write a script to enable and disable the Disable Alerting. Since there wasn't any specific function in the scripting to set this field, it required using a Run SQL script command.
update agentcomputerdata set NoAlerts = 1 where ComputerID='@computerid@'
Pretty simple, but then we wanted to ensure that it was set back to 0 some time later so my solution was to add two more steps to the script. Step 2 was to put the script to sleep for a while, say 30 minutes then run another sql command to set NoAlerts back to zero (same sql statement with a 0).
I was pretty happy with that, but then Bill Morgan from LabTech suggested that we just add an enable and disable script to our maintenance script groups and then we wouldn't need to treat it as a separate item. I think we might have come to that conclusion on our own as we decided *where* we would schedule this script, but it was another one of those ah-ha moments.
The best part of this is that it will cure one of our most common mistakes, rebooting a server without first suspending alarms. Yes, about 50% of the time when a tech schedules a reboot (outside of or normal maintenance window), they forgot to suspend the alarms in Kaseya. Because rebooting is a script AND disabling of alarms is a script, why not just combine the steps? By combining these two scripts we will no longer even need to think about suspension of alarms.
DW
Wednesday, July 21, 2010
SNMP Continued
So the SNMP stuff was cruising along until we hit another little snag. We ran into an issue where the system that we had the agent/probe installed had a conflict on port 69 for TFTP. The problem was that the LabTech agent internal TFTP server would run before the systems TFTP server effectively preventing the system TFTP server from starting. This was only an issue when the endpoints for the system (this happens to be a VoIP system) needed to refresh their configurations. Since they used TFTP to get the updates, it would fail since the LabTech TFTP server had nothing for them.
The bad news *was* that we could not change or disable that in the LT agent. I spoke to Kevin at LT about the issue a few weeks ago. I spoke to Kevin and a couple other guys yesterday and they informed me tha the next maintenance release will include the ability to disable these via a registry setting! Since we don't need those particular services for anything we are doing on the box it will be a perfect solution for us. So now we are back in business (or at least when the update is released which should be very soon).
DW
The bad news *was* that we could not change or disable that in the LT agent. I spoke to Kevin at LT about the issue a few weeks ago. I spoke to Kevin and a couple other guys yesterday and they informed me tha the next maintenance release will include the ability to disable these via a registry setting! Since we don't need those particular services for anything we are doing on the box it will be a perfect solution for us. So now we are back in business (or at least when the update is released which should be very soon).
DW
Wednesday, June 9, 2010
SNMP Update
I haven't posted anything about this topic for a while. The good news is that it seems to be working very well to receive traps. The bad news is that the main reason that we needed to do this threw us a little curve. It turns out that the device that we are receiving traps from sends many (a lot) of "informational" traps like software version number, etc every 30 seconds. So we end up with 100's of traps received, but it is just a bunch of noise.
We are working with the vendor to get the proper OID's of the traps so that we can use the SNMP trap filtering to accept only what we want. Once we get that we will be in good shape.
One thing that would be incredibly useful in the SNMP trap mechanism in LT would be the ability to send the name of the trap definition along with the alert. Each entry you make in the SNMP trap table has a name/description field. Unfortunately, this information is not passed with the other alert information. I think that Kevin submitted it as an enhancement request.
It is my understanding that LT has some significant SNMP enhancements on the roadmap. In my opinion, the current SNMP stuff is pretty good and at least better than what I was able to do with K.
DW
We are working with the vendor to get the proper OID's of the traps so that we can use the SNMP trap filtering to accept only what we want. Once we get that we will be in good shape.
One thing that would be incredibly useful in the SNMP trap mechanism in LT would be the ability to send the name of the trap definition along with the alert. Each entry you make in the SNMP trap table has a name/description field. Unfortunately, this information is not passed with the other alert information. I think that Kevin submitted it as an enhancement request.
It is my understanding that LT has some significant SNMP enhancements on the roadmap. In my opinion, the current SNMP stuff is pretty good and at least better than what I was able to do with K.
DW
First 200 Kaseya agents removed
So we finally started removing Kaseya agents. Yesterday we removed appx 200 agents across a number of clients. We are moving slowly to ensure that we haven't missed anything, but I really feel like we are equal or better than we were in our workstation monitoring/alerting now.
The only issues so far have been primarily with getting MAC agents installed, but luckily we don't have a lot of them and we weren't doing much with the Kaseya agent on the MAC's anyway. Labtech is helping us with this.
The other issue is that we get some false positive Master Computer Offline alerts. I need to run this by LabTech support, but it doesn't seem to be causing us any issues.
Our biggest issue right now is that we have clients in two systems which will cause the techs a little grief. The techs have been using LT for the majority of their work for the last few weeks, so it isn't too big of a deal.
DW
The only issues so far have been primarily with getting MAC agents installed, but luckily we don't have a lot of them and we weren't doing much with the Kaseya agent on the MAC's anyway. Labtech is helping us with this.
The other issue is that we get some false positive Master Computer Offline alerts. I need to run this by LabTech support, but it doesn't seem to be causing us any issues.
Our biggest issue right now is that we have clients in two systems which will cause the techs a little grief. The techs have been using LT for the majority of their work for the last few weeks, so it isn't too big of a deal.
DW
Wednesday, May 26, 2010
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
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
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
Subscribe to:
Posts (Atom)
