FastTrack: "Complete Replacement for PowerShell?"

I recently got a press release about "Fast Track Scripting Host" (http://fasttrackscript.com), and when I saw an ad for their product I figured it was time to check it out. The product alleges to be "the one stop shop for scripting admins," and "a replacement for VBScript, PowerShell, Bat files, KiXtart, and all other Windows scripting tools." That's quite a bold set of statements!

FastTrack is a product you have to install on any computer where you wish to execute your finished scripts. It can be used for logon scripts, but it will need to be deployed to your client computers. The cost - including the first year of maintenance - is as high as $18/seat and as low as $5.93 a seat in quantities of more than 10,000. So a 5,000-seat shop is going to pay about $36,000 for the first year. That's a hefty investment, so let's look at what the product gives you in return.

FastTrack is a scripting language - it's just a very simplified, task-specific scripting language. In fact, it strikes me as remarkably similar to KiXtart, which was originally intended to make logon scripts easier to write. It has a lot of built-in functionality that would be common to logon scripts:

SyncDir [UserDocumentsDir],[UserHomeDrive]\Backup
If UserIsMemberOf SalesStaff Then ConnectShare J:,\\AcmeServer\SalesShare

Two quick examples from their Web site. The emphasis is on each line of code accomplishing some task, rather than more complex programming constructs - although as you can see, the language is very similar to both VBScript and KiXtart.

The current version of the product (6) is heavily focused on logon scripts, although it also includes support for unattended software installation, Active Directory, and a few other areas.

After using the product for a few hours, it works exactly as described - but I don't think it's something I myself would buy, or that I'd recommend to my customers. Here's why: The problem we all had with VBScript was less its complexity and more the fact that it couldn't do everything. It was all well and good until you ran into some task that just wasn't possible, because Microsoft hadn't given VBScript any "hook" into that task. So VBScript was great for a lot of things - and horrible at others. FastTrack will be the same way, because you'll be stuck with whatever functionality the vendor chooses to build into it. I'm sure they'll continue updating the product for as long as its economically feasible, but that doesn't mean you'll immediately be able to do everything YOU need to be able to do.

First, let me state that I think the logon script problem domain is a bit overstated. As we move more and more of our clients to Windows Vista and Windows 7, more and more of what logon scripts used to do can be accomplished with no scripting whatsoever, by using Group Policy objects and Group Policy Preferences. Printer mapping, drive mapping, and so forth are all becoming easier, and I think administrators ought to keep that in mind.

My other big problem is in how the vendor positions PowerShell in particular as "programming," and plays on the fear many administrators have of programming. While PowerShell HAS scripting capabilities, it is not a "scripting language," and you can be (as I've said before) very effective with PowerShell without needing to learn to program. That said, PowerShell IS Microsoft's way forward with administrative automation. You're going to have to learn something - FastTrack may well offer a shorter learning curve, but it isn't a zero learning curve. Are you going to invest in that, which might not be available in your next job, or would you rather invest in something standardized and first-party (Microsoft) supported that WILL be in whatever Microsoft-based environment you work in? 

My last and biggest problem with FastTrack is in how the company presents itself in comparison to PowerShell. I worked for SAPIEN Technologies for years, and our biggest competitor was Windows Notepad. I know how tough it is to compete against first-party software like PowerShell - but unfortunately FastTrack's marketing team has gone a little off the deep end with their comparison chart at http://www.fasttrackscript.com/Docs/ComparisonChart.aspx. Some examples:

  • PowerShell requires "multiple script lines" to create/update/delete registry values. Not true: By leveraging the HKCU: and HKLM: drives, you can perform these tasks with single commands, just as you could create/update/delete a text file with a single command.
  • Moving AD users, computers, groups, and OUs also requires "multiple script lines" in PowerShell. Not true if you're using either the Quest or the Microsoft AD commands, both of which are free and supported back to Win2003 domains. In fact, both of those sets of commands can accomplish far more in AD than FastTrack can.
  • Graphical menus are "not possible natively" in PowerShell - hardly true. Not simple (although SAPIEN's PrimalForms and upcoming Visual PowerShell products will vastly simplify the creation of GUIs within PowerShell scripts).
  • Create/update/delete files and directories in PowerShell "requires multiple script lines." Outright untruth: Simple commands like Type, Del, Copy, Move, Ren, and so forth accomplish these tasks just as they always have in Cmd.exe and even MS-DOS.
  • Query system information also "requires multiple script lines." Not true: Get-WmiObject can retrieve a wealth of information with a single command. Query and control services requires "multiple script lines," another untruth: Get-Service, Stop-Service, Start-Service, Set-Service, and so forth are all simple commands with straightforward syntax.
  • Log events requires "multiple script lines" - nope. Write-EventLog. One command. I'm picking and choosing examples, here, but in general the entire case for FastTrack is, as best, vastly overstated. Looking at their proprietary scripting language, I could duplicate most of those tasks in PowerShell with a single command - and being able to do those things with a single command is the product's entire selling point. 
  • "Send email natively" requires "multiple script lines." No, it requires you to run Send-MailMessage, a single command - much as in their product.
Another downside for FastTrack: You do have to deploy it. You have to deploy PowerShell, too, until you get onto Windows 7, which comes with PowerShell preinstalled. As we start moving onto Windows 7, you'll get PowerShell built-in for free - making it even tougher, in my mind, to justify a third-party scripting language.

One area where FastTrack excels: Permissions management. PowerShell's reliance on Get-ACL and Set-ACL, both of which require significant understanding of underlying .NET Framework structures, is awful. I hate mucking around with permissions in PowerShell, I really do. FastTrack provides easier "SetDirPermissions" and "SetDirOwner" style commands that I think Microsoft could take a cue from. That said, I find XCacls.exe incredibly easy to use, and it works great from within PowerShell. Still, if I were writing scripts that needed to do a lot of permissions management, I'd look hard at FastTrack - although the price may be a bit steep for just that.

There are some miscellaneous stuff that FastTrack does which is, in fact, tougher to do in PowerShell: Setting desktop wallpapers, for example. A few things, and probably too few to justify the price tag since there are ample examples on the Web of how to do those things in PowerShell (and ultimately, it doesn't matter if it's 50 lines of code if all you're doing is copying and pasting to make it work).

FastTrack also has a very nice editor for its proprietary language, and the company is correct in that PowerShell's native editor (the PowerShell ISE) is minimally-featured. That said, PowerGUI is an excellent (and free) editor that far surpasses FastTrack's, and commercial editors (PowerGUI Pro, PowerShell Plus, PrimalScript) are light years beyond what FastTrack offers - and they cost a tiny fraction of the price. PrimalScript, for example, goes for $299 - less than the cost of 20 seats for FastTrack. Even with a $249 SAPIEN maintenance plan, PrimalScript costs less than 31 seats of FastTrack. Do you have more than 31 seats in your organization? PowerShell Plus and PowerGUI Pro cost even less at $145 and $199 respectively.

As a "complete replacement for PowerShell," FastTrack's marketing team is really stretching the truth. The whole point of PowerShell is its open extensibility, even by third parties. PowerShell can manage Exchange, SharePoint, SQL Server, System Center products, and many Windows components (with more on the way) including IIS and Active Directory; of all these, FastTrack includes only partial support for Active Directory - hardly making it a "complete replacement" for PowerShell. And that's ultimately my point: Microsoft has dozens of product teams churning out PowerShell commands for you to use; FastTrack is one company that can never hope to turn out the same amount of administrative functionality. 

Yes, PowerShell is more complex to learn. No question. It's a matter of investment: My feeling is that the investment you spend in learning a proprietary language like FastTrack will pay off very little (not to mention having to convince the boss to shell out for it); the bigger investment in PowerShell will pay off exponentially more, even if you write only simplistic "scripts" in PowerShell and stick primarily with executing commands.

But there are definitely administrators out there who are TERRIFIED of anything that even remotely resembles scripting, who may find FastTrack to be more approachable and easier to learn. In those cases - go for it! My experience with the product shows it to be capable and well-made. In fact, once you start using it and realize that you really ARE scripting, you may be inclined to give PowerShell another look. Of course, since PowerShell costs you nothing, it might be nice to give it a look first, just to make sure. Despite the many crazy-complicated examples you may see on the Internet, performing basic administrative tasks with PowerShell is actually much more like running command-line tools in Cmd.exe. 

In short, I think FastTrack may be a valuable product for an administrator who, for whatever reason, (a) refuses to learn PowerShell, (b) has needs that fit entirely within what FastTrack delivers, and (c) doesn't anticipate moving beyond his or her current job anytime in the future, thus expanding his or her needs and requirements. For anyone else, I continue to believe PowerShell is an incredibly valuable investment. I'm not saying that because I'm passionate about PowerShell; that's the REASON I'm passionate about PowerShell.

Let me acknowledge to the naysayers out there and admit that PowerShell is not a cross-platform nirvana, is not an end-all be-all tool, and will not solve every problem. That is not the position I'm taking. My position IS, however, that PowerShell is more capable, more valuable, more extensible, and more flexible than FastTrack. My position is also that FastTrack's makers aren't being completely honest with you in their comparison chart and other literature. I also acknowledge that FastTrack may be easier to learn that PowerShell - but I'll stipulate that it's because PowerShell can do so much more. If you were to ONLY focus on those parts of PowerShell that do what FastTrack does, I bet you'd find a similar learning curve in both cases. Looking at this list of commands that FastTrack supports (in their documentation), I can find single PowerShell commands that correspond to about seven-eighths of them.

Is FastTrack better than VBScript? Yes, for the tasks that FastTrack is able to complete. No question. VBScript was never specifically made for administration - its use as an administrative tool is almost accidental. It's a generic scripting language; in most cases, the real work isn't being done by VBScript, but by various COM objects that all look and work differently and are really tough to learn without a programming background. If your choice was FastTrack or VBScript, and your needs fell within FastTrack's capabilities, I'd tell you to scrounge up the cash for FastTrack if you could do so.

Should you take a look at FastTrack? Yes, absolutely - you should never take some writer's word for anything when you can get your own look for free (a 45-day trial is available at http://www.fasttrackscript.com/Download/Default.aspx). However, read through the marketing literature with the grains of salt I've tried to provide. Don't fall into the trap of thinking that PowerShell is a "scripting language" that is ALWAYS complex, because for many of the tasks FastTrack accomplishes, PowerShell is no more complex than FastTrack (e.g., running a single command to accomplish a single task). If you decide that FastTrack is a fit for your company - awesome. My overriding goal for all technology is "whatever tool gets the job done fastest, wins." If you hate PowerShell and think that FastTrack is greater than sliced bread - good for you! I'm sure FastTrack's authors will appreciate your enthusiasm, and I'm sure you'll be successful. I just want you to be able to make an INFORMED decision.

Your thoughts? Does a simplified, proprietary, task-specific scripting language beat out PowerShell in your environment? Why or why not?

Discuss this Blog Entry 15

on Sep 17, 2010
Wallen, you're right, I did a couple weeks back - I got really burned up seeing their marketing literature. I decided to pull the article and spend some time with the product to see if maybe I was missing something, and then spend a bit more time and write up a more formal review. So I did, and here it is. Thanks much for your thoughts!
Wallen (not verified)
on Sep 17, 2010
Gah! I wish one could edit comments!!!

Another typo...

"anwhere from deploying PCTechs to do inplace software upgrades"

Should be:

"anwhere from not deploying PCTechs to do inplace software upgrades"







Wallen (not verified)
on Sep 21, 2010
Oh... and I guess I should post a disclaimer.

I do not personally know Don, nor do I work for any of the places that he has produced learning products.

I guess you can call me a fan of his work, since it has helped me out immensely.

So, my recommendation of one of his products is completely from my personal opinion (and personal experience), as an easy way to get started with Powershell. I'm not some marketing shill... so take my opinion for it for whatever you think it is worth.

Thanks







Thomas (not verified)
on Sep 21, 2010
The deployment part is not true. When you set up a login script, you get a boot thing that copies the engine to the users appdata directory before executing the script. It does say that too in the very first section on the vendors home page.
Peter (not verified)
on Sep 21, 2010
Hi Wallen

Thank you VERY much for your hints!

I checked the product out. I get your point, but honestly, can any of us really write a bit synchronizer in vbscript or powershell without using a third party util? Let’s say for the sake of argument that graphical interfaces are easy with powershell, could we create the same graphics ourselves? And the price, it’s actually extremely cheap for small companies. I can probably get one day of training for the number of licenses I would need.

But. Powershell is free and it’s Microsoft. So I will give powershell a chance, but this product is nice, so that’s the backup plan.







on May 12, 2011
Don,

It is a bit off topic for posting here, but not sure how else to reach you.
In the article above you mention logon scripts being (largely) replaced or simplified by GPOs and GP Prefs, I have to say I disagree with that, specifically with some of the examples you cite. Having said that maybe I am missing something, you lood at this stuff all the time, I am just an admin in a small company so my time to evaluate these things is slim.

To provide one simple example, drive mappings in GP Prefs cannot be effectively used in my environment (and I suspect many others) if you want to be able to provide mappings when users log in to their local system not connected to the corporate network via software VPN for example. Since much like the call a "logon script" functionality in Windows the drive map function of a GP Pref process must occur at machine log on...WHY????!!!! I can use a script to map a drive anytime.

I am way off base...?






Wallen (not verified)
on Sep 17, 2010
Whoops... typos

"monitory script that my predecessor din in VBScript"

Shoul be:

monitoring script that my predecessor did in VBScript

And what I meant by "more efficient" was that his script took hours to run due to the way he was doing things, mine takes minutes and provides the same info. I'm not criticizing my predecssor, either... he was brilliant. He just didn't have the same tools as I have nowadays.







on Sep 20, 2010
Peter, you absolutely should. That said, I think PowerShell requires the same level of cleverness as FastTrack does, provided you're approaching PowerShell as a command-line interface and not a "scripting language." I know it's very popular to think of PowerShell solely as a scripting language, but that's definitely only one approach. If you can master a command like...

Send-MailMessage -To "someone@company.com" -Subject "Mail Alert" -Body "This is the body" -From "me@company.com" -Attachments c:\files\attach.txt

...well, then you're going to do fine with PowerShell... or with something like FastTrack. Although PowerShell, through its various extensions, provides a lot more coverage and capability.



Wallen (not verified)
on Sep 17, 2010
Didn't you post something similar around a week ago then pull it?

In anycase, I agree that their advertisment of Powershell's "complexity" is a lot of hooey. I just got done re-doing a patch monitory script that my predecessor din in VBScript. With powershell I did it faster and more efficiently, and in 1/15th of the code (1500+ VBScript lines vs. 101 Powershell lines (including comments))

Powershell is easy as pie, and I'm no application developer. I can make 1600+ machines "dance to my tune" when I want, how I want, almost whenever I want (often have to schedule for non-production hours). I've saved our agency tons of money anwhere from deploying PCTechs to do inplace software upgrades, to not having to buy expensive monitoring / central patching software that you are limited to what the vendor provides. All thanks to Powershell. I believe it truly is superior to the *nix shells / scripting environments.



Peter (not verified)
on Sep 19, 2010
I will certainly check it out. Not everyone is as clever as you two at scripting.
Wallen (not verified)
on Sep 17, 2010
Oh... and (Sorry for the spam)... It only took me 2 days to develop / redo something that was fairly complex in the first place.
Wallen (not verified)
on Sep 18, 2010
I don't think anyone that has spent any reasonable amount of time working with Powershell will fall for their marketing. Unfortunately, they will probably grab a few IT Folks that don't know any better.

It's the same thing with the little project I just described. We've been patch monitoring and patching via scripting for years. I'm talking about 3rd party software, like Acrobat Reader, Java, Flash, etc. etc. - not our WSUS stuff for Microsoft products. We had a vendor come in to try and sell us some big fancy patch management software product, which would have cost around $30,000.00 + maintenance. Just about every topic they brought up... I had to reply "we already have a system in place to do that".

My point is... Some IT Folks will get "wowwed" by a package like that, and get their company to pay through the nose for something that can be done with relatively little development time with scripting - for FREE. We're probably talking the same or less development time as it would take for the learning curve for that fancy patch management package. ...And I have more granular control ...and it's customized to the way we do things ...and I can add more functionality on the fly (Not limited by the vendor's functionality). If these folks would only take the time to really dig into Powershell, they could easily solve tons of issues that crop up, and avoid buying "unnecessary toys" to do the same job.



on May 12, 2011
Wow Wallen, I have to agree with that, wish I could edit a comment statement you made. I wish I had proof read it better too.

last full line first paragraph should be "..., you look" not "lood"

last line of post should be "Am I..." not "I am"



Wallen (not verified)
on Sep 21, 2010
Peter,

I highly recommend the CBT Nuggets videos on Powershell (and Don is the instructor). That's how I got started. Once you see the power demonstrated with your own eyes, you can easily grasp the concepts and move on to intermediate book google or examples of what you want to do, and join a couple of Powershell forums to ask quesions / get answers.

That will get you up to speed in no time.

I went from barely being able to code in VBScript (Because I didn't have a need to use it often in the position I was in) to an intermediate Powershell user within a couple of months. It's been a little over a year... and I'd say I'm fairly advanced now, but there are tons of folks on the the "Scripting Guy's Forum" that are "heads and shoulders" above me, and I'm no-where near in the same caliber as Don.

The really cool thing about Powershell is... the more you use it and learn... the more value it will yield for you and your organization. And as Don mentioned in the article... it's a skill you can take with you as you further your career.

I kind of feel like Don is being the preacher and I'm shouting "Hallelujah"... but as I said earlier... I've saved our agency some serious cash in several instances, due to Powershell. And that's a good feeling to have in this day and age.









on Sep 18, 2010
Wallen, I couldn't agree more. I once had an admin in class (at a conference) tell me that they weren't "getting into" PowerShell because they could just buy GUI tools to do whatever. Well, I guess with an unlimited budget and a willingness to live with whatever the vendor provides... that's a plan!

Please or Register to post comments.

What's PowerShell with a Purpose Blog?

Don Jones demystifies Windows PowerShell.

Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×