Autodesk products growing dependence on "prerequisite software"

[Anonymous]

It's getting increasingly difficult to deploy network versions of newer
Autodesk products to a large user base of 300 staff. The trend is for
Autodesk products to require an increasing litany of prerequisite software,
such as versions of MSXML Parser, various versions of MS .NET Framework, MS
Visual C++ 2005 and 2008 Redistributable, etc, etc, etc. As the quantity of
prerequisite software components grows, so does the failure rate of network
deployments grow.

Recent examples: Revit Architecture 2010 network install includes a
containerized or "wrapper" version of a .Net Framework multi-version
installer that attempts to upgrade computers from .Net 2 sp1 all the way to
.Net 3.5 Sp1 (and updating the cumulative .Net 2.0 to SP2, and 3.0 SP1 to
SP2). We're finding a very high failure rate (~50%) where .Net Framework
3.5 never makes it there, then stalls on trying to install MS Visual Studio
Tools for Applications 2.0 and the Runtime for that app.

Autodesk NavisWorks Simulate 2010 often fails on one of it's own components
called Autodesk Navisworks 2010 6-DWG File Reader Runtime, and checking the
network deployment log file, it reports a rollback for Navisworks Simulate
and Navisworks Freedom, thus the product doesn't get installed. Again, the
failure rate is high, perhaps as high as 50%.

There are workarounds to some of these defects, but it is requiring an
inordinate amount of time to repair failed network installations of Autodesk
products. Because the problems are often related to a Microsoft or Apple
"prerequisite" software component that don't install properly, and even
though these components are provided by Autodesk network product deployments
and called by their installers, there is a sort of hands-off approach when
dealing with Autodesk technical support and reporting installation failures
of their products.

The pain for CAD Managers is forever growing.

--
Mark McDonough
Sasaki Associates
http://www.sasaki.com

[Anonymous]

Agreed 110%.

The problem with .Net is that it is constantly a moving target. Autodesk freezes
their internal development based on the state of .Net which is also frozen at a
certain point of time. When a service pack or update comes out for .Net (usually
thru MS Update) it can negatively affect Autodesk software.

With installations, whatever Autodesk uses to identify the state of .Net on a
machine usually breaks as well.

Matt
matt@stachoni.com

[derel]

I'm with both of you - network deployments are becoming much more time consuming having to prep all the pre-req software to go out first. How are you guys deploying your Autodesk products and how are you dealing with the pre-req software? I'm currently using group policy, but so many of the pre-reqs require aditional work to work since they don't come as .msi - wondering what everyone else is doing.

[wundrlik]

I have things a little easier (I only manage 30 Vanilla ACAD users). I run my test deployment after I build the network deployment, then I contact our IT group and have them install all of the pre-req stuff through their software distribution tools (IBM/CA tools). After they have confirmed that the software is successfully installed on the PC's in my group, I begin the deployments myself to the local machines. The only thing that sucks is that I have to manually kill the AV and watch for it to return once or twice during the installation. They "do not under any circumstances" allow the users to manually disable the software through the regular channels (in fact 99% of our IT group doen't have that right either)

I have to admit though, that the deployment engine for 2010 got much better over 2008/2009.

I have to agree with you though, all of the pre-req's are killing efficient and streamlined installations of Adesk software.

Ryan Wunderlich
Royal Caribbean Cruise Lines