Autodesk Scripts: TKO

Maybe I'm drinking the wrong Kool Aid.  Maybe I'm just being paranoid?  Maybe I'm giving myself waaaaaaaay too much credit.  But it seems that lately when I post some script code for doing something with respect to deployment (or "un-deployment", one of my favorite words to chuckle over), Autodesk publishes their own version and trumps me soundly.  I dunno. 

Whatever the case, my focus has always been on making it possible to run "unattended" for massive scale environments (read: Microsoft System Center Configuration Manager, or Altiris, or whatever), while Autodesk is focused on making a thorough script (or KB/support article) that is designed to work interactively (someone runs it, not via an automated agent or scheduled task).  Case in point: KB Article TS45252.

Rather than try to "compete", or engage in some sort of "race", I'm bowing out.  Autodesk wins.  They have battalions of younger code monkeys with infinite more time to accomplish more in less time.  They have the means to do a better job than do I.  My resources, time and enthusiasm are much lower.  Call it "Low-T" or whatever, but as I approach 50 I'm starting to rethink my priorities.

As a tip for anyone still interested in (more-or-less) "porting" Autodesk deployment and removal scripts for use in an unattended scenario:

• Look for MSIEXEC statements that use /qb! and replace with /quiet /norestart
• Look for instances of "WindowsInstaller.Installer" that use the ConfigureProduct method, and modify the UILevel property from msiUILevelBasic to msiUILevelSilent (note that msiUILevelBasic = 3, and msiUILevelSilent = 2)
• Look for MsgBox() statements and replace them with Wscript.Echo
• If the MsgBox() statement is used in the Function form (returns a value) force the return value by hard assignment (e.g. intChoice = MsgBox("Continue?", vbYesNo, "Caption"), just set intChoice = vbYes)
• Add error checking throughout and make sure to "raise" errors using Wscript.Quit(err.Number).  If you are running the .VBS from a .BAT or .CMD script, be sure to raise the error again from there user the DOS "EXIT %errorlevel%" statement.
• It helps to add secondary condition checking and raise forced errors if needed. This is helpful for things like making sure folders are deleted, registry keys are removed, and so on.
• Follow the MSIEXEC error code advice I posted a few days ago here.

Finally, I'm not saying that I won't ever post relevant code here again.  I'm just saying that unless it's something truly unique and provides added value, I'll let it go by the wayside.  I should have learned my lesson when AutoLISP was left out in the cold to starve and die slowly.  I guess I've been too nostalgic and sentimental about it all.  Time to grow up.