Guns and Butter

'Guns and Butter is an economic term to illustrate options in resource allocation.  Do you (as a country) pour your efforts into your military?  Into your people?  Or some of one and some of the other?  If the latter, what ratios do you use?

Your MSP business faces a similar quandary, except replace Guns & Butter with RMM & PSA.  You've only limited development time and resources - where will you spend them?

Having been with LabTech for five years now, I've spoken with countless IT support companies in the process of transitioning to a Managed Service Providership.  These companies have similarly numerous philosophies on how to do it so I've seen all sides of the coin - some houses only want RMM, others treat it as a necessary evil and focus all available efforts on the PSA.

(Warning: potential RMM bias alert!) It seems to me your RMM is the meat and potatoes of your MSP business and everything else is... well, everything else.  While not optimal, I'm sure I can provide (much!) more value to my customers being RMM heavy as opposed to being PSA heavy.  Sure I may be losing a few bucks in inefficiencies but then again, maybe I'm not if you consider the savings of NOT building that tracking.

No, of course I'm not advocating you just let rip and 'see what happens'.  That's a poor business model no matter how capable you are.  Conversely so is micro-managing.  What do I mean by that?  Let me give you some example questions I've heard to demonstrate:

How do I make LabTech add time for every automatic remediation it performs?  How do I track this?
How do I detect a new workstation or computer has come into the environment and pro-rate the introduction date against the monthly rate?

The problem with this strategy is that this is yesterday's business model - and the world is changing.  The above questions assume we're trading time for money but the philosophy behind MSP is exactly opposite.  We need to deliver a more 21st century business model.  Something a little more...  Netflix(ish).  Their model: give us a buck a month and have all ya want for that month.  'Ya ate a ton?  Great!  Ya ate nothing?  Great!'  Either way, the next question is: 'Would you like another month of service?'  Now, instead of bean counting they can focus their efforts almost exclusively to service delivery (and new subscriber acquisitions.)  Not a bad business model, eh?

If you focus your efforts almost exclusively on your customer's environment, you'll soon be stunned how little effort is required to maintain it.  First you'll need to learn how to script - in Windows and in LabTech.  Learn application packaging and automate both deployment and onboarding events.  Learn policy management and apply it using both Active Directory and LabTech (bonus points for using LabTech to automate Active Directory GPO's)  Do these things and you'll find no matter what your customer comes up with, not only can you do it - you can automate it.  This is the core of profitability for a Managed Service Provider.

Of course you'll want to do some risk mitigation (e.g. structure it so if LabTech agents are removed, ALL your automation ceases operation within the environment.)  Now, bill like the insurance companies do: based upon risk.  Does your customer insist everyone needs to be a local administrators?  That should cost more than a more regulated environment.  Are you enabled to automatically push anti-virus to any computer without it?  If so, that should ease the cost of providing MSP services as there a little less risk.

There are other considerations to this tactic.  Next, we'll talk about hiring 300 and the inherently disruptive nature of this business model (and the natural implications of such.)  Stay tuned!

This Powershell thing is kinda useful

A LabTech user says 'Rob, I need to create a search for all Windows Servers that have the Windows
Server Backup feature installed.  How do I do this?'

Well, this is a bit of a problem as the LabTech agent doesn't pull Server Feature metrics.  So we'll need to rely on another metric such as an Extra Data Field (XDF).  The trick is to tie the feature installed/not installed to the XDF.  That way we can provide a search for that (or any other) Windows Server feature.  For this we need a script.

Before we whip out our script editors, we ought to first determine exactly how we plan to pull that metric.  Best case is that we can query the registry for a yes/no.  Unfortunately, if that registry key exists, I couldn't find it.

So we're stuck w/ a WMI call.  Bah, what a hassle!  This requires us to create a .VBS script that queries the namespace, add some logic to iterate thru the MOF and then pull the needed metrics.  Whoops, don't forget the error-handling!

There's got to be a better way.  And sure enough, there is: Microsoft's PowerShell.  We can query WMI thru the PowerShell.  Even better yet, we can actually structure our query to one line.  Like this:

get-wmiObject win32_serverFeature | select ID | where {$_.id -eq "39"}

To paraphrase, this query is looking for an ID where the ID = 39.  Now, check this link.  You'll find a list of all the Win32 Server Features in WMI.  If you go thru the list, you'll see that 39 is just what we're looking for:  'Windows Server Backup Feature'.  If the target computer does have the Backup Features installed, then the query will include an ID of 39.  Of which, of course, the ID will necessarily = 39.  Simple, eh?

So to get a LabTech to offer a Server Feature search, we just need to flip an XDF based upon the output of this script.  In my environment, I created an un-editable, computer-object checkbox XDF and assigned a script to my Windows Servers that:

PowerShell Command (yep, the very same one listed above)
If %powershellresult% contains 39 then :CheckTheBackupCheckbox
If %powershellresult% not contains 39 then :UnCheckTheBackupCheckbox

Take a minute to go thru that Microsoft reference page.  Do you see any Feature types you'd like to have a LabTech search for?

Finally, you may want to create more scripts like this.  What's the best way to test?  Open a target server, open the CMD Prompt tab and send powershell commands right thru LabTech.  Just be sure to preface the command with the tilde (~) and LabTech will display the output.  Pretty cool, huh?

"It can't be done" (Part II)

As soon as one asshole shows up to say 'it can't be done', some other asshole shows up and does just that.

"It can't be done"

Next time you hear 'it can't be done', consider this guy and remember: there is a virtue to having a can-do attitude!

Other LabTech Webs

Here's a few more resources for those of you looking for more LabTech content and contacts.  HatTip to Samy of Stack Advisors for these links. (thanks Samy!)

GitHub - https://github.com/ManagedITStack

Subreddit - http://www.reddit.com/r/managedit/

IRC - http://webchat.freenode.net/?channels=%23%23labtech&uio=d4 (##labtech on the freenode IRC network)

Reporting on Failed Logons

A question was sent to me: how can we be notified if someone tries to sign onto a desktop or server with bad credentials?  I really like this question because monitoring failed logins is an excellent service to offer an environment.  Windows doesn't do this by default and knowing missed account logins can be very helpful. Most of the time this monitor will help you take care of an end-user who may have legitimately forgotten their password.  Sometime however, it will give you a heads-up that your environment is under attack!  Either way, knowing when a login attempt fails on a computer is a proper monitoring metric.  Let's see how to realize this with LabTech.

Now, out of the box, a Windows system won't post to the event logs when a login fails so that's the first thing that needs to be addressed.  If we look at some documentation, we can see this feature can be enabled using Group Policy.  Well, that ends that - LabTech can't speak Group Policy.. right?

If that's your initial thought then you really ought to check the link just under this post.  If so, you'll see that the vast majority of Group Policies can be actualized through the registry with edits (and therefore can be done by LabTech).  OK, so we can easily make this change then.  Well, unfortunately this security policy seems to be one of the exceptions.  Look up the aforementioned path and find that 'Event Log security settings are not registry keys.'  Meh.

Turns out, this can be done without Group Policy.  I found a command: auditpol which lets us apply this policy to a local computer.  Three lines later, we have a new LabTech Script: 'Enable Failed Logon Event Logging'.  It looks like this:

1.  SHELL:  auditpol /set /subcategory:"logon" /success:disable /failure:enable and store the result in %shellresult%
2.  IF %shellresult% = The command was successfully executed. THEN Exit Script
3.  Create Informational Alert: Policy Modification Failed

OK, so now we can tell a computer to turn on failed logon auditing.  How then to monitor it?  The answer and the testing process are one and the same here.  First, apply this policy to all the computers types you are responsible for.  Next, fail a logon.  Using LabTech, tell that remote computer to inventory the log files.  Do you see a new entry for the failed logon?  Right-click, create remote monitor.  Done and done.

Best link ever

For a scripter working in Windows, here's the best link you can have.  MS group policy settings!