This posting is intended to list issues for large-scale deployment techniques using Autodesk installers. It’s my manifesto for Autodesk Application deployment: I’m a big fan of Autodesk software, but I’m often frustrated with trying to get programs installed for people. This is maybe a long whiney list of issues, but also a list of suggestions for Autodesk. Addressing these problems would make their products the best in the market at ease of deployment and maintenance!
1.Acquisition
It is difficult to acquire all the necessary files for a complete installation. It generally takes me more than a month, with an average of 2 attempts per file (sometimes as many as 6 attempts are required (12+ GB of downloads) to acquire working deployment files. If you have many products, this adds up! I download in the neighborhood of 50 products per year, English, International, Metric, Imperial, 32 bit, and 64 bit.
Multiple Locations
Before downloading files, they have to be found. Currently there are 4 locations (subscription Software, Subscription Updates, Autodesk.com service packs, Autodesk KB for bugfixes and minor repairs) that must be scoured for applicable files, and there’s no single list of the files available relative to a software release.
Customers, especially subscription customers, should have a single list somewhere that provides us with ALL installs related to a product. Subscription tools, extensions, Subscription and Non-Subscription service packs, along with associated GUIDS and BUILD NUMBERS. This list should be available as an RSS/twitter/linkedin/facebook feed so that we can keep track of multiple programs without having to actively check the list for changes. The list should be sortable and filterable, and include; Application install, List of Service Packs, List of KB installs, List of Extensions, List of Subscription tools, list of service packs for subscription tools. Each entry should include a build number, link to the download, list of dependencies/prerequisites (SP-2 needs SP-1 or doesn’t it?) and release date. It would be so easy if we just could see a big table with all the values filled in;
| Column | Contents |
|---|
| ID | (Unique ID) |
| Product Family | (Revit, AutoCAD, 3D Studio, Inventor, etc.) |
| Member of Suite | (AutoCAD/Revit MEP Suite, etc (Tied to our Subscription Information)) |
| Licensed | (True of False (Tied to our Subscription Information)) |
| Product Name | (Revit MEP, AutoCAD Architecture, 3DS Max Design, etc.) |
| Version | (2011, 2012, 8.1, etc.) |
| Operating System | (Windows XP-7, Windows 7, OSX, Linux, etc.) |
| 32 Bit Compatible | (True or False) |
| 61 Bit Compatible | (True or False) |
| Release Date | (2011.05.04) |
| Update to a Previous Release? | (True, Link to Previous, or reference to row ID) |
| Install Type | (Deployment, Service Pack, Subscription Advantage, KB, Extension, Content, Tutorial, etc.) |
| PreRequsites | (Revit MEP, SP1, etc.) |
| GUID | (4bcc6b9d-cba1-4a10-bac4-d9f52b1e0fcf, etc) |
| FlexLM ID | (699003DSMAX_2010_0F) |
| Description | (Optional) |
| Download Links | (Link directly to download(s), not to download page.) |
| Silent Install Command | (setup.exe /w /qn) |
BUILD numbers need to be more prominent – visible in every install, every splash screen, and every deployment creation dialog box. This is the only way to know sometimes if a product is up to date, and it can be difficult to find in many applications. A standard location for a text file containing the build number would be nice for access by scripting tools!
Perhaps consider a list of appended numbers to the build number to identify the presence of extensions and SAPs so that we can use the CAD Manager tools and other network management tools to easily identify computers that need updates in a consistent way, and so we can easily identify what the current build number should be if a user is to be "Up to date".
Autodesk ID
The Autodesk subscription ID login occasionally stops working, sometimes during downloads. Checking the “Keep me Logged in” option on the login screen doesn’t keep you logged in. Sometimes, checking that box will result in login failure, and I’ve had to request password reset numerous times after trying this option.
Download Size
The download files are very large, single files. I don’t know if there’s any way to avoid this, but it can take weeks to download a full set of applications, and 30% are usually corrupt when completed. The browser download, in conjunction with Free Download Manager has been the best performer, but sometimes login permissions will be reset during a download and cause it to fail. The built-in download manager (on the website) rarely works.
CRC and SFV files would be helpful – so we can validate the download before waiting 20 minutes for it to extract files to find out whether it’s corrupt.
Multiple smaller pieces would be helpful… maybe just a series of 20MB RAR/R01/R02 files would be easier? So that regardless of download size and technology, a download can be resumed or repaired without starting completely over and each piece can be CRC checked before you use them so they can be replaced if damaged.
2.Deployment maker
- All deployment makers should work the same.
- They need to run much, much faster. Determining installation requirements?? How? It’s a DEPLOYMENT, and shouldn’t be reading the current OS for anything
- They shouldn’t delete all deployment files if a service pack fails to apply during deployment creation.
- Make it completely clear if multiple deployments can be put in the same location. Can you really set up 3 deployments in the same admin image folder and have it create 3 shortcuts and INI files that work? Even if some are 32 and some are 64 bit? …for all applications?
3.Unattended Deployment
It is difficult to create unattended deployments that are successful in a large, multi-location environment.
Consistency
ALL extensions, Worksharing Monitor, Robot Extensions, Batch Print, Subscription Advantage Tools, etc. should have the same structure, either msi /qb, or .exe /SILENT or something, ANYTHING, that allows us to deploy silently to multiple users, from the administrator account, for all user accounts, in both 32 and 64 bit environments. Also, all installs (deployment, extension, or otherwise) need to function such that the command line, Start /Wait setup.exe... command will actually wait until the deployment has completed
Also, Can we name folders and shortcuts consistently? Is the installation going to be in C:\Program Files\Autodesk\Appname YYYY\, or C:\Program Files\Autodesk Appname YYYY\? Will the shortcuts be Appname-YYYY, or Autodesk Appname-YYYY, etc. Same goes for the registry entries. Not that it matters which way the programs are named to us, just pick one method and stick with it! It makes many other automated and scripted processes much simpler if we don’t have to custom hard-code a path for every Autodesk product each year.
Consistency in 2012 deployments
Revit Architecture 64 bit deployment warns on each shared folder that content exists and you can answer ‘NO’ to overwrite… doesn’t appear to have any affect. In 32 bit it only asks the first time.
Deployment dependency in installed programs
Updates should not need to refer to the original MSI Path in order to succeed. If the original MSI is needed, it should be placed in the install directory and referenced there.
Silent, Wait options in deployment maker
The ability to run silent and wait (setup.exe /w) should be in all deployment makers. Deployment makers should also allow the addition of not just service packs, but extensions and Subscription Advantage Packs as well. It would be nice if Autodesk would provide other extension developers the ability to make their extensions compatible with this format, so that tools from SmartBIM, Avatech, Ideate, etc. could also be included in a deployment.
Another suggestion, provide a deployment maker for all additions, so that service packs, subscription advantage packs, and extensions can be added as they become available without having to try to custom-script the install (which often entails extracting files from the exe, writing a command line, and putting that command inside of a bat file that checks for the appropriate installed programs (See Consistency, above)
Deployments also must be able to provide for multiple user profiles. If installation happens under a network-managed, local admin account, this shouldn’t affect the required permission level of the user. Files should not become read-only or inaccessible in the install directory or support directories simply because of the permission level of the user who logs in after the deployment has run.
Simple uninstall procedures;
Applications should uninstall remotely and easily through a command line that works consistently for all projects. Uninstallations of multiple related installs (Like Navisworks Manage and Navisworks Language Packs) should either take care of all associated related installs at that time, or the removal of one shouldn’t make it impossible to remove the other. Maybe the best solution would be a “Completely Remove” exe, or a negative deployment that could be made by the deployment tool for the product.
4. Portability & Maintenance
Location-Dependency in deployments
Deployments need to be made consistent for multiple locations. This generally means 1 person creates a deployment and provides it to others, in other locations to execute. Deployments should not contain the UNC Path to where they were created as part of the deployment in any circumstance. I have been able to manually replace this in the deployment.ini with %~dp0\... This should be the default. This allows us to create standard deployments and move them to other locations without breaking the deployment. This applies to logfile paths as well!
Network Content
Deployments and service packs should never, ever, ever install content by default. All paths to configuration files need to be editable to allow the installation of software in an environment where shared parameter files, templates, library content, hatch patterns, various config and ARG and PCP files, are all stored in shared network locations. It’s OK if those locations must be written into the deployment, as long as they’re all able to be mapped paths (B:\Config\Acad, B:\Config\Revit, etc.)
Web Content
Downloads should never, ever be forced by a deployment. Installs may need to download content and check for updates, but once a deployment is created, ALL required content should be on the local network. 500 Revit installations trying to download material libraries is a disaster.
Upgrade and Maintenance
Service packs should never install content, ever. If content dependency exists, it can be paired with the SP (with instructions and a zip that extracts both installs), but the content must be upgraded separately. If it happens to be in a
Many of these things are acomplished by some versions of some products, but many are not. Do they test their installers? at the command line? what about the uninstallers/ Does anyone else find they have issues with deploying Autodesk products?
I'll be presenting at Autodesk University 2011 in Las Vegas. We'll be discussing the management of large multi-file, multi-building, multi-team projects. (LF5038 At the Design Leadership Forum before Autodesk University, on Monday, November 28th 2011 in Marcello 4504 at 1:00 PM-2:00 PM) 
