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?