While you’re there, you should also have out David Walsh’s ebook, Source Control. As David says, “if you’re not outsourcing, you’re either about to get crushed by someone who is, or wasting time on worthless tasks.”

Nowhere in my mind is this more true than in the MSP market where we’re now at MSP 2.0. Everybody is using the same tools and price is now becoming a differentiator – ultimately, cost pressures are going to go up and outsourcing the routine, mundane, boring and specialized tasks is a smart way to cut costs. Outsourcing is hard, but David’s book really helps simplify the process.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

One of my clients attempted to resolve this problem and in their NOC/helpdesk they run a custom built dashboard solely dedicated to server offline alarms, but they found a couple of major problems with this:

1. Consultants are busy and it may be 10+ minutes before they glance up at the dashboard and pickup on server down alerts – generally the client has called in before that anyway
2. Consultants are based in multiple states and whilst not located at the NOC, many of these consultants may be assigned to helpdesk and NOC duties – without direct access to this dashboard, remote consultants found it difficult to track server offline alerts.

A Desktop Alert tool for Kaseya?

This clearly wasn’t good enough with over 400 servers under monitoring. So, in conjunction with this client, we developed a desktop application to alert their consultants in realtime when a server goes offline – the consultants are alerted via a popup and audible alarm. The solution has been working well for the past few months with a few refinements and iterations to the tool. (Sorry, no screenshots available as contains the client’s branding which they do not want made public)

They’re now at the stage where they want to expand the capability and flexibility of the tool. They’ve plonked down some cash to get the tool built and figure that the tool has worked well for them so surely there’s other MSPs who could benefit. So right now, they’re looking to offset the cost of software development by commercializing the tool and sharing with the community – that’s where you come in!

Register your EOI in the comments section…

Before creating a formal EOI for the tool and investing a heap of time into the project, we want to know whether you as an MSP would be interested in such a tool and if so, please post in the comments. If we get enough traction in the comments section over the next 30 days we’ll open up a formal EOI and get started on the project. We’ll be looking to a freemium model for the tool, with the free version limited in some way, most likely ad driven and the pro/premium version and pay per license monthly subscription model (no more than a couple of bucks per month per user).

So, what do you think? Could this be useful in your MSP business?

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I LOVE GOOGLE ADWORDS!

I think adwords is fantastic. For less than a buck, you can get your business website listed on Google for search terms that relate directly to the products and services you sell.

Many businesses dabble in Google Adwords, some with success, others not so much. Adwords can be an expensive proposition and if you make a mistake it can be costly but here’s one quick way you can improve (probably dramatically improve!) the effectiveness of your Adwords campaigns. You’ve probably even thought about this yourself before.

Here’s the secret: Harness the power of spelling mistakes.

How often do you type the wrong search term into Google? I do it at least a few times a day. If you do regularly use Adwords then you’ve probably got a few common mis-spellings of your company name or key product or service in the list of keywords. It’s not really economical to work out every mis-spelling by hand but here’s a simple tool that can automate the process for you and in doing so, unlock thousands of new search terms that you probably never thought of and what’s even better, few others or nobody else will be bidding on.

So here’s the tool I use: Keyword Typo Generator

All you need to do is load up the tool, type in common and relevant search terms for your business and the tool will spit out of list of mis-spelt keywords. From there, import the keyword list into your Google Adwords campaign and your done. Your business will now show for a whole new bunch of relevant search terms with little or no other competition!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

It still amazes me the volume and number of alerts and events that MSPs are handling “manually” or with human labour when Kaseya can in many instances auto-heal or auto-resolve the problem.

One area where this is really evident is around disk space monitoring on workstations or end user PCs. I’ve seen many MSPs handle each and every alert for low PC or workstation disk space. The machine runs out of disk,  the technician calls the client, tells them they have low space and asks them to cleanup their files and so forth. The number of times workstations run out of disk space and the sheer number of workstations MSPs manage can make this a massive real dollar cost to an MSP business. On the flipside, ignoring low workstation disk space is likely to cause you to breach SLA or your monitoring obligations.

Here’s how I handle workstation low disk alerts and maybe how you should be handling it too!

• I monitor for 750MB free or less for more than 2 hours – I do this using a monset instead of the inbuilt disk space alert. The inbuilt alert pulls its data from the last audit and is not realtime. Therefore not really reliable to use in a monitoring sense. It’s also based on % free, on a 500gb disk 5% free is a lot more than on a smaller disk, say 40gb so again you’ll get big variances in the quality of your monitoring with this approach.
• Instead of alerting/alarming where a human has to intervene, I automatically trigger a script that generates a popup telling the user they have low disk space and that we’ve queued a disk cleanup for them. It also advises them that they need to cleanup their files as they’re out of disk and if they need help in doing this, then to call the helpdesk.
• Kaseya will then trigger a series of scripts that runs Windows Disk Cleanup, Clears IE History and runs Windows chkdsk
• After the scripts are done, they then write an information event to the Windows Event Log recording that the machine ran out of disk (so that a technician that may be troubleshooting an unrelated problem for the user knows Kaseya has worked on the machine) and I also write an event to the Kaseya agent log.
• I then have a weekly report that shows all machines that have run out of disk space in the last week – this enables you to keep an eye on the status of workstation low disk alerts without investing a massive amount of time. You can also use this to show low disk space activities on your Executive Reports.

I really love this approach as it’s totally automated once setup, it’s still proactive, it delivers real value to your client and they actually see this value, it’s easy to report on and most of all it removes the majority of the cost associated with monitoring workstation disk space thresholds.

If you need help getting your Kaseya monitoring back on track I’m available to help – head to the Contact Us page and drop me a line and we can talk further.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.

I’ve had a truckload of enquiries lately about patch management and patch management configuration. I whacked up a variation of this post on the Kaseya forums a while ago. Here it is again. I’ve rolled out this config to quite a few kserver deployments and its bulletproof so long as the config is maintained and is deployed properly for each new machine group.

If you’re struggling with patch management I’m more than happy to assist – head over the Contact page and drop me a line.

The different areas of patch mgmt that need to be configured are:

• Patch scan/audit scheduling
• Patch approval policy setup & management
• Patch source management
• Patch source bandwidth management
• Patch deployment schedule
• Post patch reboot config

Patch scan/audit scheduling

I usually scan workstations every 2-3 days and servers every 5 day at night. Why I first started with Kaseya I had everything doing scans daily but as agent number grew to several thousand agents this really started to hurt the box at peak times. Scheduling at a longer interval doesn’t negatively affect patch deployment once machines are up to date and significant reduces load on the kserver and sql backend.

Patch approval policy setup & management

I have two master groups, workstation & server and all machines are member of one or the order. I then have two policies specifically for each client, workstation and server again. By default patches are all pending approval. I generally only use the master policies unless I specifically need to approve/deny a patch for a client. For example with IE8, some end clients wanted it, some clients it would break for particularly if they were using line of business apps that were browser based. So with my approach I can approve patching on an individual client basis or across the entire system and neither method interferes with the other.

Patch source management

Here I use a combination of pull from internet, from system server, from local file server (which then is configured to pull from system server or net). I also use bandwidth control in conjunction with System Server source to throttle patch deployment. This where you’ll come unstuck with patch management if you don’t deploy and maintain your configuration properly. I like to automate my template deployment for machine groups so I can setup templates and then don’t need to worry about patch management configuration on a regular basis.

A lot of Kaseya deployments I deal with have clients with remote offices on slow links so the download from system server option is a great way to deploy patches at a throttled speed. I also heavily utilise the chassis type – often applying different policies to desktops and laptops at a site as laptops can often be away from the LAN for several weeks at a time and might need a different configuration.

Patch source bandwidth management

I generally apply different bandwidth policies to servers, desktops & workstations depending on remote office speed. I also use the naming policy feature along with auto applied templates to reconfigure laptops as they move between branch offices to the patch management config for that specific branch office. My general rule here is to use 9kb/sec for workstations, 25kb/sec for servers but ultimately this depends on their link speed.

Patch deployment schedule

Again, different schedules depending on whether the users are at a branch office, desktop, laptop or server. Generally speaking, desktops and laptops are weekly or daily and servers are manually deployed. At some sites we have prearranged server outages weekly to allow for patch deployment and then just approve policies in the approval policy and the patches auto deploy. Once more, here’s where you’ll fall down if you don’t maintain this proper. I recommend keeping your configuration documented in a spreadsheet centrally so you can keep track of how each machine group and type of machine should be configured.

I like to use daily patch deployment for workstations where I can because once workstations are fully up to date, this setting doesn’t really have any negative impact on end users and as patches start deploying the same day or within 24 hours of being approved. This really makes critical patch deployment much more simplified.

Post patch reboot config

Generally, nothing reboots after patching unless it has been pre-arranged. When I first started with Kaseya a few years ago I used to configure agents to hassle users for a reboot but this caused too many unexpected dialog boxes that users hit OK on and lost work. It also caused unnecessary inbound helpdesk phone calls. If I really absolutely need something rebooted, I used a script or send message function under the remote control tab.

I also recommend you run a fortnightly report showing you workstations that have no been rebooted in the last fortnight and servers that haven’t been rebooted in 90+ days. << Yes some admins talk about Windows server uptime like they’re a hero if they can keep a box up for several months at a time but in the real world, Windows Server needs to be rebooted. Ultimately we’re trying to reduce support overhead and rebooting servers as part of general server maintenance to me seems to resolve more issues than it causes.

Anyway, hope you find this information useful and would love to hear from you with any suggestions, improvements or feedback.

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.