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!

Automating the Automator (Part II)

At this point we have a script that does one thing – deletes a computer from LabTech.  But we still need to identify the computers that we want to remove, then call our delete script and aim it at the offender.  What do we want to remove?  In my case, it’s simple: anything that hasn’t reported in over 30 days will be wiped.  How can we identify those computers?

I'll be honest and say I cheated and leveraged something I knew was already in the system.  I’ve long noticed that most of the internal monitors in LabTech have some sort of time constraint in the ‘Additional Field’ section so I used SqlYOG and did a little experimenting with the bit of SQL the monitor provided.  After a little bit of trial-and-error, this is what I came up with:

SELECT computerid FROM computers WHERE lastcontact < DATE_SUB(CURDATE(), INTERVAL 30 DAY)

As I’m marginally proficient with SQL, I did a lot of testing on this simple string.  This includes inverting the comparator, modifying the days (30) and both while for every run, making absolutely sure the results returned matched my expectations.  Once I saw that happen no matter how I arranged the string, I was confident I had a working query.  Now to the next step; let’s build one more script.

New Script - If ‘True’ Then:

Line 1 Function: Script for Each SQL

• SQL: computerid as DeleteMe FROM computers WHERE lastcontact < DATE_SUB(CURDATE(), INTERVAL 30 DAY)
• Script To Run: (point this to the first script we created)
• ODBC Connection: (leave empty)

Name it, uncheck ‘Computer Script’, save it.  Done.

Note the SQL line is slightly different from what we tested.  This is so our output table is named with a non-standard name.  I wanted to make it clear for this exercise exactly what is getting passed between these scripts and how and a custom name does just that.

We use the ‘Script for Each SQL’ function because we don’t want to make assumptions of how many computers will be detected.  With this logical loop, it doesn’t matter if none, one or one-hundred targets are identified.  In all cases, the next subsequent action will take place (deletion.)  This makes our script flexible and prone to working properly.

If you are curious as to how our scripts pass their parameters, take a look at the ‘Script For Each SQL’ function carefully.  Note the top where it reads: ‘Performs a SQL Query and runs  a script for each row returned setting all returned columns to internal variables like this %sqlCOLUMNNAME%’  Now look at the first script we made yesterday.  Note the query – call sp_DeleteComputer and run it on %SQLDeleteMe%.  We create the column of computers which haven’t reported in 30 days – assign the ‘DeleteMe’ column name to the column – and reference it the way the script notes instructed.  Make sense??

The last step is to schedule this script for execution.  Again, please don’t do this on a production server until you’ve seen this work on your test system!  Dashboard -> Management -> Scheduled Client Scripts.  Add the script we just built to the list for daily execution and you’ll never again see a computer in your LabTech system that hasn’t reported to your server within the last 30 days.

Safety First!  One last suggestion.  Edit your delete script to add one line in front of your delete line.  If SQLDeleteMe = 1 then Exit Script.  ComputerID #1 is most likely your LabTech Server and we probably don’t want to delete that entry.  No, I can’t think of a situation where your LabTech server wouldn’t report in for 30+ days and get deleted.  Then again, it’s free to add a simple line to the script that might save my butt….

Automating the Automator

The Control Center doesn't allow multi-selections so removing multiple computers from inventory seems impossible, right?  Here, I'll show you how to do this with a script but I hope you take away more than just one simple script. For with LabTech you can automate the LabTech server too - not just your remotes. There's lots of reasons to do this; this is just one example.

To setup for this, you'll need a test system with SqlYOG installed and a few vm's reporting into it. Use SqlYOG to open the database and look inside. Check the stored procedures. Is there a sp_DeleteComputer procedure? Open it for editing and you'll see it's looking for two properties: the ID of the computer to delete and a reason for deletion. Makes sense - when I use the GUI to delete a machine from LabTech, it knows the computer ID from my selection and the first thing it does is prompt me for a reason to delete. OK, now for the next step.

Next on the list is for us to confirm that stored procedure 1.) works as expected and 2.) is perfectly understood in exactly how it works.  Yes, I understand this is a simple stored procedure but before you rush to scripting before first testing, consider this: how much of a hassle will it be if you accidently delete the wrong computer from your production server?  What if you accidently delete more than just one?  The short of it is, you always need to test your automations before coding them.  Really.  A little effort here will pay in the long run.  Especially when those automations are running against your LabTech server.  OK, 'nuff said on that...

...so lets do this!  (Now is a good time to do a snapshot of your test environment.)  Open SqlYOG and the LabTech Control Center on your test server.  Identify the ComputerID of a vm we can delete (mine is lucky #7) and move over to SqlYOG.  Enter in this string:

call sp_DeleteComputer('7', 'Deleted thru SqlYOG')

...and press F9.  This will execute the line and, presumably delete computerID #7 (I really hope you substituted '7' for your run.)  Go back to the Control Center and refresh.  Check the navigation tree.  Is the computer you expected to be deleted, in fact, removed from the tree?  Good!  Now that we know this works as we assumed it should and we know exactly how to work it, we are ready to solidify it in script.

[aside: If you don't already have one, I suggest creating a 'Tests and Examples' script directory.  Unless you are the only person working in your LabTech server envrionment, there's always a chance someone may run one of your scripts as you are building it in a production environment... unless that script is in a directory named 'Tests and Examples!'  (Or, at least if they don't, you'll have plausable deniability for the ensuing chaos ;)  ]

New Script - If 'True' Then:
Line 1 Function: SQL Execute

• SQL Query: call sp_DeleteComputer('%SQLDeleteMe%', 'Deleted by script')
• ODBC Connection: (leave empty)

Name it, Uncheck 'Computer Script', check 'Function Script' and save it.  Done.

My editor is telling me this is a perfect opportunity for a cliffhanger so let's table this for a day.  Tomorrow, I'll show you how to schedule this script for daily operation and aim it at computers that haven't reported in over x days.  Until then, Happy LabTechIng!

Move: Done

A tough week of moving pains has paid off and we’ve just completed moving our corporate offices to a new location.  Accomplishing this while gearing up for Automation Nation -and- maintaining service levels was a challenge, but certainly worth the effort as we are now settled into our new – and much more spacious home. Go LabTech, v 5.0! 

I have to say, it’s absolutely amazing to have seen the transition of LabTech from a two-man back office to taking two floors of a sizable building.  Never mind the explosion of our user-base from 20ish to over 2000...  While words cannot fully express my awe and gratitude for our partner base and your overwhelming support for our product, I’d still like to extend my deepest thanks to each and every one of you who use our software to make IT problems go away and environments more stable.  We couldn’t have done this without you!  Whatever version of LabTech the future holds, you can be assured that each and every one of us here remain committed to delivering you the best RMM software experience available.

Later this week, I’ll bring pictures so you can see the new digs.  Until then, thanks again everyone and  -Happy LabTech’Ing-!

(re)Ignited!

Welcome back faithful readers! I'm happy to report my blog hiatus is now officially over. Lots has happenened and there's tons to talk about but that will keep for later posts. This first-in-a-long-time post is instead dedicated to LabTech's Ignite! I have to say, my hat is off to the team for such an excellent execution of a terrifically difficult job. You think it was tough setting up your 2011 system for your environments? Kevin and his team had to setup the system for *everyone's* environment! This is LabTech's first real lean-into in this realm, and I couldn't be more proud of the results. That's not to say there aren't a few bugs and perhaps even a /facepalm or two in there as well (if you have Ignite, go set your default template's priority to 10. Do it now) but considering the immense value Ignite delivers right out of the box and all that it does right, I think we can forgive some mistakes. Ignite lives up to its name by lighting our LabTech servers on fire! OK, that's enough; I'm coming dangerously close to sounding like a fanboy. So let me close with a heartfelt thanks! to the team that made this happen... and a request for your experience with Ignite. I'm very interested in knowing your story with it so if you'd like to share, please hit the comments and post them up! (blogging LabTech is fun; it's good to be back :). )