Happy Automation Week!

If you are a LabTecher then this is a must-attend event:  Automation Nation 2013 is finally here!  I'll be there Tuesday and if you tell me you're a reader of this blog, you'll win a free drink.  You can two-fer it if you tell me you've also run one of my posted scripts, either from here or LabTech Geek but be prepared for questions!

Happy LabTeching everyone, hope to see you in Orlando.

Can LabTech modify a/some/all user profiles?

Of course.

Normally I don't recommend a script I haven't first tested, but as it's from The Man, it's probably a safe bet.

Nonetheless, all standard disclaimers apply.  ;)

Are you a LabTech Geek?

Then you ought to know about this:    http://www.labtechgeek.com

Happy LabTeching!

Update

I know I've two half-written articles below.  Be patient, dear reader!  I'll come back to them soon enough but having learned a great deal about PSA's over the last couple weeks has made me rethink the Guns and Butter article.  I may have lept to an incorrect assumption and want to dig deeper before making a final judgement on this.  Regardless of the result, I must admit it really looks as though I may have made a rash initial decision.

Solved: How to enable LabTech remote uninstall

Uninstall Application vs. Uninstall Application User.  What's the difference and why are there two buttons for one process?  The most common workflow when someone new to LabTech finds the software uninstall option is to try it, then report to support it doesn't work.  What is going on under the covers and (more importantly) how do you make it work?

This command is no different from most other LabTech commands in that its run by the Local System Account (LSA).  What happens when you press that button is the exact same thing as if you did it on the local computer in Add\Remove Programs.  99 times out of 100, you'll be prompted 'Are you sure?'  Thing is, the LSA can not paint to the desktop so no one can ever see that prompt.  It sits and waits for a response that never comes and meanwhile it looks to the technician that the command has failed.

If you're skeptical try this next time: send the command to refresh the local processes.  I bet you'll see an msiexec.exe in there.  That's your uninstall prompt waiting for a response and that's the point of Uninstall Application User - it is run by the LabTech Tray (which is running in the user's security context) so the user will see the prompt and can click it for you.  In a pinch that's OK but we don't want to build a service offering around that jenked process.  How do we click that button?

We can't - we have to make it so that dialogue never occurs, just like if you had checked the 'In the future, don't show me this dialogue box'.  How do we do that progromatically?  Simple - use the registry!

You should use this process on every application you deploy thru LabTech.  This way, anytime you need to un\re install an app, you won't need to interrupt the user and you'll have 100% full control of all the application on a remote computer.  For example, on my ConnectWise install script, I've the following line:

Registry Set Value: HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\DontShowMeThisDialogAgain\{948e51fb-0a48-44f0-86ac-33c36def540c} = NO (reg_sz)

Now my right-click, uninstall application button in LabTech works flawlessly.

Remember, real men don't click. (hat-tip to an old web page that was mighty helpful back in the day)  Hope this tip helps you in your endeavors and Happy LabTeching everyone!

Does anyone have any experience with Adguard?  It seems to work very well with little overhead - can anyone out there say differently?

Find the last computer that joined your LabTech Server

Quick and easy:

SET: @sqlIdOutput@ = SQLRESULT[SELECT MAX(ComputerId) FROM computers]
SET: @sqlClientNameOutput@ = SQLRESULT[SELECT clients.name FROM clients JOIN computers USING(clientid) WHERE computerid = '@sqlIdOutput@']

Create Informational Alert on ComputerID #1:  The latest computer ID is @sqlIdOutput@ and can be found as a member of the @sqlClientNameOutput@ client.



[UPDATE]
(Hat tip to fellow LabTecher Kevin D for calling this out)
It seems there's an assumption in this logic.  It holds - UNLESS you've used the resignup utility.  If you have, we can't assume the highest computer ID = the last computer to be added.  Thanks Kev! (sorta.. )

Quick Scripting Suggestion

When creating a new LabTech script, I very often find it advantageous to do a variable dump.  This allows me to check my assumptions against what's actually going on inside my LabTech server.

How do you do this?  Very simply - just add one line of script to your existing script:  
RUN SCRIPT:  _System Automation\Functions\Show Variables*
Go ahead and shim that line on any script and run it.  Next, open the target computer you just ran it on and open the 'history' window.

Finally, click on the 'Scripting' button on your History window and click to highlight the script you just ran.  If you look just under that, you'll notice a similar entry - but this one doesn't have a 'Script Status'.  That's the one you want.  Click that line and look at the bottom half of the screen.  It's shows *all* of your variables!  Here's an example:

Here is the list of all available variables: Script Variables - use @ instead of @=
@=computerid@=1
@=ltrunbyuser@=Admin
@=clientid@=1

Internal Variables - use % instead of %=
%=assettag%=
%=backuppass%=pass
%=backupserver%=ftp.yourdomain.com
%=backupuser%=user
%=brandingtitle%=LabTech Channel
%=bytesin%=338
%=bytesout%=372
%=cachedir%=%Windir%\Temp\LTCache
%=cachepass%=
%=cacheuser%=
%=clientaddress%=
%=clientaddress2%=
%=clientcity%=
%=clientcomments%=
%=clientcountry%=
%=clientcrmguid%=
%=clientexternalid%=0
%=clientfax%=
%=clientid%=1
%=clientname%=LabTech Channel
%=clientownername%=
%=clientphone%=
%=clientstate%=
%=clientsupportmins%=0
%=clientversion%=51155
%=clientzip%=
%=computercontactid%=0
%=computerdomain%=.
%=computerid%=1
%=computeridletime%=0
%=computername%=Test Offline Server
%=computerpassword%=asdf
%=computeruserdomain%=.\administrator
%=computerusername%=administrator
%=cpuusage%=12
%=domain%=WORKGROUP
%=featureflags%=0
%=lastuser%=WORKGROUP\SYSTEM
%=localaddress%=10.44.186.31
%=localltshare%=C:\LTShare
%=locationaddress%=
%=locationcity%=
%=locationcomments%=" "
%=locationcontactid%=0
%=locationcountry%=
%=locationdrive%=
%=locationextra1%=
%=locationextra2%=
%=locationfax%=
%=locationid%=2
%=locationname%=Main Site
%=locationpass%=
%=locationphone%=
%=locationrouter%=1
%=locationrouteraddress%=
%=locationstate%=
%=locationuser%=
%=locationzip%=
%=ltshare%=L:
%=ltsvcdir%=%windir%\LTSvc
%=mac%=12-31-38-1D-D4-D1
%=maintenancemode%=0
%=majorversion%=51
%=managementip%=10.44.186.31
%=managementport%=3389
%=memoryavail%=506
%=minorversion%=155
%=nasdrive%=\\NAS
%=noalerts%=0
%=os%=Microsoft Windows Server 2008 R2 Datacenter x64
%=proxypass%=
%=proxyserver%=
%=proxyuser%=
%=redirhostname%=ltchannel.hostedrmm.com
%=redirpasscode%=4937
%=redirport%=70
%=reliablity%=0
%=routeraddress%=10.44.186.1
%=scriptid%=5811
%=serviceversion%=51.155
%=sitename%=LabTech
%=snmpcommunity%=
%=space%=
%=supportemail%=support@ltchannel.hostedrmm.com
%=tempdir%=%Windir%\Temp
%=tempfiles%=416813044
%=threadid%=3143
%=totalmemory%=1699
%=uptime%=4067
%=uptimeend%=23:59:59
%=uptimestart%=00:00:00
%=username%=IP-0A2CBA1F\LTAdmin
%=virusap%=0
%=virusdate%=0
%=virusscanner%=0
%=when%=4/2/2013 3:06:05 PM
%=windowsdirectory%=C:\Windows


Cool, eh?  ;)

Big vs Small - Forging an effective MSP business

In terms of effective and profitable RMM service delivery, which is it better to be: a small one or two man shop working out of a garage or a large shop with four-hundred plus business customers?  To answer this we first need to look at the pros vs. cons within each environment.

Generally speaking, a small shop is likely to have working in their advantage:

• A high degree of price and product flexibility &
• Very few committed hours

Unfortunately, this usually means that:

• Tasks and projects are scattered &
• There's little cash in reserve

Which is really tough because:

• It's very hard to get traction &
• You're a bitch to your customer's whims

OK, lets look at the other side of the coin.  Again, generally speaking, a large shop is likely to have working to their advantage:

• A high level of product specialization and hyper-efficient product delivery &
• Known good processes for the vast majority of customer requests

Which sounds much better than Option A until you consider this also means:

• An equal amount of product rigidity &
• A discouraging environment for innovation

For a bottom line result of:

• Tomorrow's product isn't being built because
• You're a bitch to the process

Good thing I'm not a motivational coach, eh?  Neither of these environments seem to be good MSP incubators - so how and were do you find your chrysalis?  (and did I just type 100 words just to end up at the same question, said differently?)

That's just it.  There is no greener grass here.  There is no relationship between the size of your company and the ability to quickly and competently metamorphose into a pure MSP delivery shop.  The diatribe above was mostly pulled from my discussions with prospects and customers telling me why it was harder for them to make this transition.  Truth is, size just doesn't impact the formula.

What matters is organization, knowledge and understanding.  Rule #1 for building your MSP

• Know Your Windows
• Know Your Customer
• Know Your LabTech

I don't mean 'Know' in the archaic, I mean the old-fashioned 'Know', borne of gumption, ability, determination and pride.

Know your Windows.  I'd like to think this first fundamental needs no further elucidation.

Know your Customer.  This is one of your biggest competitive advantages.  This should also be your inspiration.  Ask yourself, 'What is it they ultimately want?'.  Don't think stuff like Outlook 12 and the new slate tablet thing.  Think more big picture:  they want an email front end and a portable tablet.  Then take it next level:  consider what they intend to do with that email editor and that portable tablet.  Then use your expertise to guide them to the smartest choice.  Offer them exactly what you would do, were you them.  This process may very well come back full circle to Outlook 12 and the Pro Tablet. Or it may not but that mental exercise did it's job in that it forced you to really consider your customer's needs from their shoes.

Know your LabTech.  All this means is using your knowledge of Windows and your understanding of your customer's needs to create automation that elegantly delivers exactly that.

More on this later...

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!