Kaseya Connect 2013: Scaling Services for Profitability
•Download as PPTX, PDF•
0 likes•451 views
"Have you considered service delivery for scale and the functionality needed to execute it? Its important to consider the right things when planning for future growth and expansion in your business, and the key to that is how your business will scale, both from an operational standpoint and in detail in how you use Kaseya to scale your delivery. Find out some of the finer points to help you plan as well as what needs to be in place to support the services operationally.
Recommended
More Related Content
What's hot
What's hot (13)
Viewers also liked
Viewers also liked (10)
Similar to Kaseya Connect 2013: Scaling Services for Profitability
Similar to Kaseya Connect 2013: Scaling Services for Profitability (20)
More from Kaseya
More from Kaseya (20)
Recently uploaded
Recently uploaded (20)
Kaseya Connect 2013: Scaling Services for Profitability
- 1. Scaling Services for Profitability: Things You Need to Know Miguel Lopez Sr. Technical Director – Enterprise Solutions
- 2. Agenda • User Access • Policy Manager • Procedures • Service Desk • Event Logs • Review
- 3. User Access • Access to what people need – Change management • Create Views specific for use – User Views – Policy Views • Prefix: zz_
- 4. Policy Manger • Policy Configuration
- 5. Policy Manager (cont.) • Policy per client • Exception Policies – No Overrides
- 6. Procedures • Identify common tickets 1. Malware/Virus tends to take the top 2 or 3 spots depending on the organization 2. Password Issue 3. Email does not work 4. Computer is running slow - Not related to Malware 5. Internet Access 6. Printing Problems 7. Access to File/Folder 8. Application Problem/Error 9. Backup/Restore a file 10. Frozen Computer
- 7. Service Desk • Identify common alerts • Investigate and document process • Replicate process with automation • Explore what to present to engineers
- 8. Event Logs • Only gather those events you need • Stay away from capturing events • Minimize the log history – Agent > Log History • Alternate methods
- 9. Event Logs - KAV • Create policy view for KAV • Use Policy Manager to run script every 15 minutes • Email sent to SD for ticket creation <?xml version="1.0" encoding="utf-8" ?> <queryList> <queryDef label="KAV Infection" sql="Select top 1 name from Kav.ThreatDetection WHERE agentGuid = +++GETVARGUID: AND type NOT Like 'legal%' order by DetectedTime DESC" /> </queryList>
- 10. Review and Evolution • Go back and check your configurations – Identify that business reasons still exist • Look for more efficient ways – Product upgrades – Product familiarity
- 11. Questions
Editor's Notes
- Hi, my name is Miguel Lopez.I have been using Kaseya for over 7 years. As a result, I am very familiar with what it can do and how to do it. The last 5 months at Kaseya, I have been working with clients that have larger installs. Helping them identify the things to look at when they are trying to grow vertically. Some clients had issues where the systems were running slow and other just wanted some advice based on their growth plans.As a result, I decided to put together the top 10 things I feel you need to know in order to use the system efficiently and to allow you to scale both your business and the system.
- Here is a list of the areas I am going to talk about. User AccessPolicy ManagerProceduresService DeskKaseya Anti-MalwareReview
- In my prior role I was part of the team that handled acquisition integration and discovered what they were doing and how they were doing it. One of the thing I found from that experience was that many companies, provide full access to most things within the system to a large portion of their technicians and engineers. If they did not, they usually provided more access than was really necessary. As a result, I have seen people make changes to the system where they did not follow the a process or they did not know why the setting was in place to begin with. Many will argue that this is a result of a communication problem but the reality is that one person can not know every detail about everything. As a company grows this becomes a bigger problem where it becomes critical to distribute the work to different people or groups of people within the organizastion. You will find that as you grow it is very difficult to train everyone on everything and keep that training up to date.Therefore, give admins access to what they need in order for them to do their jobs. This will help you ensure that the right people are making the necessary changes. The right people within your organization should be changing Policy Views, Policies, Schedules, and monitoring to name a few. You will find that everyone feels they need access to everything. While in some cases this may be more efficient it usually leads to incorrect configurations of the environments you manage. Typically you find out about these errors when there is a problem. In a moment I am going to talk about Policy Manager but before I do I wanted to discuss views and how these views should be used. You should create two types of views: User ViewsPolicy ViewsThe reason you should do this is that at times admins may need to change a view. As you know, Policy Manager uses views to assist in distributing policies among machines that meet certain criteria. What if one of those views were changed where those setting would no longer affect all of you devices but only half? Let me give you an example. Lets say you have a view that distributes a maintenance procedure that includes disk cleanup and defrags to all of the workstations you manage. An admin goes in and changes that view where the result is that half of the machines you manage will only get that procedure. You may argue that no one really should go in and change that view anyways. While that may be true there is nothing identifying that procedure to be any different. As I mentioned a moment ago create views for Users and for Policies. I suggest doing this by adding a prefix to the Policy views. Not just for differentiation the views but also for grouping them. This could be something as simple as adding a zz_ in front of it. Depending on your naming scheme, this would usually put all the Policy views at the end of the list. This makes it easier to find as well as distinguishing it from everything else.Going back to the recommendation around security access I would also make sure you setup the security for each of those views where only the people who create or change Policies can see and edit those views.
- How many of you are using Policy Manager?When reviewing acquisitions it was amazing to me that so many companies are not using Policy Manager and are still using templates. I want to tell you that if you want to be efficient and while you grow you need to be using policy manager. This module allows you to keep your business requirements standardized and compliant across all the systems you manage. In terms of how to configure the product, have your policies mirror your org configuration as much as possible. It will make it easier for those that need to associate policies with clients and to find those policies later. Here is an example where you have Base Policies that are associated with all machines and then you have customer policies that are specific to the org you will associate them with. Which brings me to my next topic two topics:
- In order to effectively use Policy Manager you need to consider creating policies for as many things as possible. Remember that the idea here it to keep things consistent. In order to do that you will like have to create a Policy per client. Many will think that this is just a lot of work. Yes you are right, it is a lot of work, but the amount of time that it takes to set it up in the beginning, pays off over time. Depending on the services you are delivering you are going to see things like custom monitor sets, credentials, and patch schedules as a few things that tend to be consistent per client. For those companies that are using Policy Manager in this manner, we find that most systems have many overrides in place. An override within policy manager occurs when you have a policy in place and then you go back to Kaseya and make a change in an area where that the policy affects. For example, lets say you have a policy which includes the credentials for a client machine or a group of machines. You then go to one of those machines and enter a credential from the agent menu. When that happens then that policy is set to be overridden by the change you made. What I usually tell clients is that you should keep your system configured where you have no overrides. Instead I would recommend you setup “Exception Policies”, which can be associated with individual machines. This would allow you to check for any machines that have overrides and clear those overrides. Investigate those overrides and probably clear them. If you find that someone changed thing incorrectly it then provides and opportunity for training. It much better to find out that a change was made incorrectly in this manner than when it affects a client incorrectly as I provided in the previous slide.
- I am asked quite frequently, where does this automation come from and what is the efficiency in dollars I will see as a result of implementing it. That number is different for every organization. There are two areas where the automation really comes into play. The first being Agent Procedures.Agent procedures, as you know, can be executed by a person or as part of a policy within Policy Manager. What I tell people is that there is really no silver bullet here. You have to do your homework within your organization. Start with listing the top 5 or 10 common, day to day things that your technicians and engineers are doing, whether its within system or on the managed machines directly. Here is an example of what I put together. Some of them may be relevant to you. Don’t try to document all of them, but start by listing the top 5 or 10. Identify those that the system can do automatically. You can handle those in two ways:via a procedure someone kicks off to do certain functionsService desk procedures that will run through a process when a certain alert comes in. I will get into Service Desk on the next slideIf malware is on the top of your list, you really need to look at implementing some malware solution. Whether your clients pay for it, your organization pays for it, or it’s a shared cost, do something. If you do have a malware solution in place then you should have procedures in the system that will automatically start a scan of the system. I would also look at implementing a solution where the product updates you when the scan is completed. Another example is to create a procedure your remote engineers can quickly edit and run to change someone's password. At a bare minimum this would save the time the engineer takes to login into a remote AD server to look up the user and make the change. When you do your investigation you will see that these minutes really start to add up.
- The example I like to use here is assuming you are using the BUDR module in Kaseya although if you think about it you can do similar things with different products. We looked into BUDR and identified the most common alerts we would receive within the system. In a similar fashion as in the last slide you start by investigating what your backup teams do when they receive the alerts you listed. In many cases you will find that they just kick off a new backup and wait for it to complete. Why would you not have the system do that for you when it receives that alert? Then you could have the system look for an update to that backup in whatever interval you prefer. Finally you could tell the system to do other things depending on what comes back or simply just present that ticket to an engineer at that time. The engineer would know from the ticket that the backup was kicked off again and failed so lets not do that again. Depending on the amount of documentation you require and what your engineer does to kick off a new backup you could save 5 to 15 minutes for one ticket. The next step would be to explore if there are certain alerts you would not want your engineers to see if they are solved by the system.
- This was not in my original presentation.I decided to add this because in the last couple weeks we run into situations with clients where the systems are growing and they have started to see latency on the system. When we check the system we have seen large databases of over 100GB but device counts of 3000 devices or less. Without mentioning names we saw one client with 200 devices. The first thing we usually check when we see this is event log collection and retention. In most if these situations they were collecting all log files for all machines where the system is collecting 100k events an hour. In all the cases I have run into our client was collecting logs files they did not need. If you need to collect logs, stay away from collecting informational, success, and failure logs. The next thing we look at is how long are they keeping these logs. The first thing we are told is that they need the logs because they need to report on them. Once we start digging we find that what they really need to do is report on the alert for that event. That being the case, then you really don’t need to keep the event once the alert is created. You could then set your event log retention to several days and keep your monitor logs for the time period you need to report.The last option, and this does tend to be more difficult, try to identify alternate methods of alerting that would not require collection of so many event logs. Please keep in mind here that the alternate method should require less resources from the system.
- I created one example that I can share with all of you. I don’t know how many people are currently using KAV. Currently, to alert out of KAV you need to collect a lot of event logs. For those of you that have worked with those event logs you probably have noticed that many of those event logs don’t supply enough information as to whether it is really a virus and if you really need to do something. You probably have noticed as I did that there is a threats detected area within KAV. That tells me that the information I need is already in the system and I just need to go tell the system to go look for it and tell me when something is wrong. I would create a View for machines that have KAV installed and then leverage a policy within Policy manager that runs this script every 15 minutes. You can set this to be some other interval. Instead of pulling data from the machine it just checks a table or view on the server. The same one that the system uses for the detections area. While I have access to support and dev I did not ask dev what table is used I went through the tables and asked. I figured it out. My point here is that anyone who understands SQL can do this. As you can see this is a very short procedure. It checks the table for that one machine. It filters out threats I know are commonly legitimate software and sends and email to my Service Desk mailbox. Now I will get an alert for an infected machine that has not been cleaned.
- The last thing I want to tell everyone is to go back and look at your configuration. Look at what you are monitoring. Check those procedures that are running and how often they are running. Make sure the amount of time you are keeping logs still makes senses. Ask yourselves “Why am I doing that?”; “Do I really need to do that?”. I say to use business reason because everyone has an opinion. What you are contractually obligated to provide to your clients is what should drive your decisions.Look for more efficient ways of doing what you are doing. Many times this applies to procedures.There are product upgrades that bring new functionality that did not exist before. One example is using labels to Id machines instead of using Procedures wherever possible. Prior to 6.3 you would need to have procedures run to look for something on a machine that would identify it. Once completed you would then be able to associate a view with that procedure and identify the machine. Labels removes the need for many of those procedures to run therefore removing unneeded resource usage from the system.The other thing I run into is that many providers created procedures a long time ago and although they work they are 45 lines long and may span several procedures. During review, we identified ways where we can reduce those procedure from spanning several procedures with 45 lines in length to something that is within one procedure and many times are under 8 lines. This comes from a combination of being more familiar with writing procedures and new functionality that has been added to procedures through updates to the system.As you grow and your business evolves your systems also needs to evolve. There are things you may find that you should be doing and there are usually things that you no longer need to be doing, at least in the same fashion. I have been in many conversation where I ask the same questions of “why are you doing this?” and “do you really need to be doing this?” to those the procedures we have identified to run most frequently and many times the response is its no longer relevant or it can be changed.If you have not looked at your configurations I urge you to go back and look at them again.
- Thank you and I hope this presentation has been helpful to all of you.