Packaging DWG TrueView 2011

Ah, Autumn.  The time of year when leaves change color, kids go to school, the breeze turns chilly and Autodesk has had time to pump out at least two service packs for their flagship products.  In this episode, we find the main character slumped over his dusty old desk, glaring into his monitor with the look of a man watching a cow being fed into a wood chipper in slow motion.  Yes, *that* look.

The familiar horrors of pushing an application out to faceless masses of “users” who hold only the lowest esteem for their IT brethren.  We slave for hours to automate and simplify their world, only to be repaid with stories of how sinister we are with our torturous diabolical treachery and techno-waterboarding.  They hate us, yet we are the ones they call when their printer stops working; mouse pointer changes color; or worse: their Facebook game locks up.  The horrors we deal with.

Today it is back to the torture room of repackaging Autodesk DWG TrueView 2011 32-bit, English version, for deployment to millions and millions (ok, a few dozen) desktop computers.  They all run Windows XP 32-bit with Service Pack 3.  We use Microsoft System Center Configuration Manager 2007.  Why?  Because it has the longest f***ing name of any product in that category, that’s why.  And because it happens to be a very good product.

Step One – Figuring it Out

There are two ways to install this beast “unattended”: Using the standard .EXE package that you download from their web site, or extract the .MSI package and all the trimmings.  “Trimmings” are important here.  I will get to those later.

The .EXE package is tempting.  Very tempting.  It provides some useful options for controlling how it launches. Let’s break those down now, shall we?

Option	Description
/wait or /w	wait for the setup.exe parent process to complete before.  Primarily used for unattended execution to allow for capturing the start and finish times and any returned “result” codes.  Used with things like SMS and SCCM for example
/script or /t	for installing from a script
/reboot or /o	force a restart (reboot) at the end of the installation
/quiet or /q	no interface or progress bar shown during install
/basicui or /qb	only show a progress bar and cancel button during install. Proceeds without interaction unless user clicks “cancel” button to abort the installation
/remove or /r	uninstalls the product
/productcode or /p	pass a GUID or vendor product code to the installer.  Autodesk typically uses a vendor product code like “AMECH” or “ACAD”
/command or /c	pass a command string to the installer
/language or /lang	specify the language/locale to the installer. most cigarette-smoking NASCAR-watching Bud-drinking Americans will use /lang en-us.

Most of these are explained in a forum post by Autodesk SW engineer Kenny Guo at http://forums.autodesk.com/t5/DWG-TrueView/DWG-TrueView-2010-silent-install/m-p/2576927  It’s worth noting that Kenny blew the description for /productcode, but that’s ok, it’s still the thought that counts.

The problem I found is that without the /reboot option you’d expect the installation to finish without forcing a reboot.  But the opposite has been true in our experience.  On every single installation via SCCM it has forced a reboot without returning a “success” code.  So SCCM reports “failed”.  Not good.  Even though this forum post by Autodesk engineer Hashim [http://forums.autodesk.com/t5/Installation-Licensing/TrueView-2011-silent-install-with-SCCM-SMS/m-p/2748424#U2748424] appears to solve the dilemna, it doesn’t.  Because it still does nothing to control the uncontrollable post-installation reboot.  That sucks.  I’m sorry but this is 2010 and we should have better control of installation packages than this.

This brings me to the second option.  If you read into that forum thread you’ll arrive at option 2: which is using the .MSI package.

The difference between the setup.exe and the DWGVIEWR.msi packages is that the .EXE uses a manifest to launch other installations as needed.  These include DirectX 9.0c, and Visual C++ 2008 runtime, and then the application installation itself.  The .MSI does not do that.  It simply runs the application installer itself… which FAILS because it doesn’t find the appropriate DirectX 9.0c bundle installed ahead of time.  This goes back to my earlier complaint/whine/bitch/moan/rant about having unique DirectX 9.0c packages for EACH and EVERY product from Autodesk.  It’s insane.  I won’t beat that up again now, however, I’m too tired.

So I first attempted a basic .BAT script to install the DirectX 9.0c components for DWG TrueView 2011 32-bit, then VC++ 2008 and then DWG TrueView 2011 itself.

Problem 1 – Running DXSETUP.exe /silent directly from the remote UNC shared location does nothing at all.  Even worse: when it bombs, it causes the .MSI to fail (look in the %TEMP% folder for msi .log file for the details) which state that you need to install DirectX 9.0 before installing the product.  Well – Duh!  Even worse-er: (I’m guessing that could be a real word) is that even though it bombs out, it returns a 0 result code, so guess what?  SMS/SCCM see that as “success” and all is good!  yay!  NOT!  It actually failed horribly and completely.  Kind of how our government works: it fails horribly and keeps a smiling face on with a clean pressed suit.  Everyone is happy.

Problem 2 – Download DirectX Components and Install Locally.  I modified the script to create a sub-folder beneath %TEMP% called DX9 and copy all the files in the source DirectX folder into that, then run DXSETUP.exe /silent from there.  That didn’t work either.  It works when run manually, but not when run from the ccmexec process thread.  Because it doesn’t wait.  Even with “start /wait” in front of it, it doesn’t wait.

Solution – Repackage the DirectX components using Wise and make an .MSI that can be run with msiexec and waits.  I’ve already explained how to do this, which was really me re-explaining how someone else re-explained what someone else explained to them, and so on, and so on, and so on… but it works, so whatever.  Also, with the repackaged DirectX module, we now have three well-behaved .MSI packages, and they allow us to use the “/norestart” option to CONTROL them properly.

So, now we can wrap it up like this…

@echo off
SETLOCAL
SET LOG=%TMP%\dwg_trueview_2011_x86_setup.log
echo %DATE% %TIME% installing directx package... >%LOG%
msiexec /i %~dps0dx9package.msi /quiet /norestart
echo %DATE% %TIME% installing vc++ 2008 components... >>%LOG%
msiexec /i %~dps0\support\vcredist\2008\x86\vc_red.msi /quiet /norestart
echo %DATE% %TIME% installing dwg trueview 2011 x86... >>%LOG%
msiexec /i %~dps0DWGVIEWR.msi /quiet /norestart
echo %DATE% %TIME% done!
ENDLOCAL
exit /b %errorlevel%

I highlighted the %~dps0 entries to help make the strings easier to read.  In case you forgot what %~dps0 means, it simply expands to the path of wherever the script itself resides, so this assumes the .bat script is placed in the same folder as where DWGVIEWR.msi resides.  Save it as “setup.bat”, create your SCCM package, create a program inside the package that refers to the setup.bat file, then create the advertisement for the program and point it to a test collection, create a direct membership entry in the collection for one or two test computers and let it roll.

Then drink up.  You earned it.