Easing the Pain of Deployment
Introduction
It’s that time of year again: Cherry blossoms and new Autodesk products. And that means a whole new round of testing, customizing, and ultimately installing. That last one—Deployments and Installs, can be really painful. The topic is a massive one, and AUGIWORLD really doesn’t want me going on (and on, and on, and on) about it. So instead, I am going to cover just a few key ideas to take a little pain out of the process.
Stalled Deployments (or not)
If you have ever installed or built a Deployment of a front line Autodesk product (Autodesk® Revit®, AutoCAD® Architecture, etc.), you have probably found yourself frustrated by a “crashed” or “stalled” install or deployment creation. However, in my experience, the vast majority of the time the install/deployment creation is not stalled, but rather immersed in some slow task that it will eventually finish if given time.
The usual technique for seeing if an install has stalled is to check CPU activity in Task Manager (Figure 1,A). Most of the time this works, but there is one situation where Task Manager will give you a false positive for failure, and it happens to be the longest lull you are likely to experience installing Revit, ACA or AutoCAD: the content install phase. Depending on the speed of your machine, you could see anywhere from 10s of minutes to hours of flatlined CPU during this phase. However, there is a better tool than Task Manager, the less well-known Resource Monitor, which is conveniently available from the performance tab of Task Manager (Figure 1,B), as well as in All programs/Accessories/System Tools in the start menu.
Figure 1
Performance Monitor gives you a more complete picture of machine activity, including drive activity. In our case, a look at the Disk trace on the Overview tab (Figure 2,A) will show many small writes occurring while CPU activity stays near zero (Figure 2B). As long as that disk activity continues, your install or deployment creation has not crashed and you should avoid the temptation to Ctrl-C out of it. Be patient. It will (eventually) finish.
Figure 2
Deployment Failure Problem Solving
Invariably you will, at some point, encounter a deployment install that simply fails. It runs and runs and when it’s done... nothing. No shortcut on the desktop, no software installed, seemingly nothing. If you do a search for “rollback” in the log file created by the deployment you will find the first bread crumb to follow. This is the indication that something went wrong, but not an indication of what did go wrong. And unfortunately, all the possible things that could go wrong are much too large a topic for AUGIWORLD. Or even a small book. However, all is not as dire as it seems, as there are just a few techniques that will address 99 percent of the failures you could encounter, before they happen.
In my experience the majority of these failures stem from a series of related issues, all of which “fail” with either an error code of 1306 or 1603. This family of failures shares a single feature—they are failures of “prerequisites” such as Visual C++ redistributables or .NET components.
These installs can “fail” if the file being replaced is still in use when the update happens, which then requires a reboot before the file is available. The error message associated with these errors is actually “Successful, Reboot Required” or some variation. However, the Autodesk installer still sees this as a failure of a required component and the main install fails also.
Alternately, the Autodesk installer may be trying to install an older version of the component than what is already on the machine. This also causes install “failures” with error code 1306 or 1603 and subsequent failure of the Autodesk product install.
Lastly, I have found that 32-bit components being installed on 64-bit Windows cause an inordinate number of these kinds of failures. This was especially true with the 2013 products, but rather less so for 2014. And because the error codes are all the same, I really don’t know if it is Autodesk installing older components or files in use or what. I just know that certain 32-bit components are more likely to be problematic.
I have found three techniques that address the vast majority of these issues.
- Always run installs on a freshly restarted machine. This minimizes the chances that a file is in use, because no programs have been launched.
- Always install using a dedicated Install user, with nothing set to run automatically, to further ensure that no prerequisite files are already in use. This is also a good security technique. Staff user accounts can be configured with limited permissions, and your dedicated “Install User” can get regular password changes, or even be deactivated when not needed. Even for a sole proprietor, I strongly recommend a “Regular” user account for daily work, and an “Admin” account (with a strong password!) for installs and the like.
- Set Ignore_Error=Yes
Go to the folder where you chose to put your deployment when you created it. There you will find your “Deployment Image” folder. For older programs this was called AdminImage, while Revit 2014 and some newer programs are using simply img. Inside this folder you will find a “Deployment INI” file, which is simply an ini file with the same name as your deployment, RVT_2014 as shown in Figure 3,A.
Open this file in a good editor (shout out to NotePad ++) and search for VCREDIST Begin, and as you scroll down you will notice a number of “x86” references. You will recall that x86 refers to the 32-bit CPU architecture, while x64 refers to 64-bit. So, what we are seeing here is the ADSK deployment trying to install 32-bit components on a 64-bit machine.
You will also notice the seed to our solution, in the IGNORE_ERROR=5100 line (Figure 3,B). This is in the out-of- the-box version of the ini file, and is simply Autodesk configuring this particular component to ignore error 5100. Obviously there is a very specific and non-catastrophic error here, and Autodesk doesn’t want the overall install to fail because of it.
We just want to take this a step further. Instead of ignoring just error 5100, you can set IGNORE_ERROR=Yes, and no error on this particular component will cause the rest of the install to fail (Figure 3,C).
Figure 3
Now, you might be the cautious type, and only want to ignore errors 1306 and 1603, but historically I have simply set all errors to ignore and I have never yet encountered a problem that could be traced back to this decision, but I have seen a massive reduction in failed installs. And again, barring actual failures traced to other items, I only take this action on 32-bit (i.e., x86) components, and only the Visual C++ components. And I add my IGNORE_ERROR=Yes at the bottom of each component to make it obvious which ones I revised. Lastly, if it sets your mind at ease at all, you will find that some of these already have this setting, so perhaps all we are really doing is picking up the ones that Autodesk missed.
One last thing to note. Thus far we have been talking about revising the ini in a deployment. However, when you are simply installing Revit directly, the installer will unpack effectively a standalone deployment in the Autodesk folder on the C drive, which will have a Setup.ini in the root folder for a particular product. This setup.ini is the equivalent of the deployment-specific ini and can be modified the same way. My preferred approach is to copy this ‘“Installer” folder to the network or an external drive (and rename the folder something short and sweet while I am at it) and modify setup.ini there. Now I can use this single shared installer image to install without waiting for the EXE to unpack, with any customization already applied. I find it useful even for a sole proprietor to keep the install image off the C: drive, and modified to minimize problems. A failed hard drive, a new machine, any number of reasons can come up for needing to re-install something, so having a deployment/installer library external to your machine is a good idea in any size office.
Copying/Migrating Deployments
There are a number of common scenarios where moving or copying a deployment is beneficial. You might have structured your deployments storage with all deployments in a single folder and now want to organize them differently—by vendor or year or what have you.
You may have also moved the entire deployment store to a new server, or simply renamed the old server.
Or, if your firm has multiple offices you may need to install from a local server if your WAN doesn’t offer the performance for a single deployment source. The ideal solution here is DFS, which allows for identical paths to local network storage. However, in the real world we often deal with not only different server names, but different folder structures at each location. Recreating deployments at each location is time consuming, and maintaining consistent settings in every deployment is difficult. A better approach is to build and test deployments once, then copy them to each location as needed. But a deployment contains references to the path in which it was created, so without a little revision the copied or relocated deployment won’t work.
The first step is to identify the pathing differences between your various final deployment locations. The portion of the path you are concerned with is up to but not including the “Deployment Image” folder discussed earlier.
In this example, I am moving a Revit 2014 deployment (the deployment is actually called RVT_2014) from an old server and folder structure to a new one. Specifically:
\\Support\Deployments\RVT_2014\x64\Img becomes
\\Px_Server\Rollouts\ADSK\2014\RVT_2014\x64\Img
Once I have my deployment relocated, I need to make changes to a number of files.
The first is the deployment shortcut, which can be found in the same folder as the AdminImage or img folder, and will have the same name you gave to your deployment (Figure 4,A).
You’ll need to right-click and choose Properties, and replace the old portion of the path with the new; once in Start In and twice in Target as you see here in the revised values (Figure 4,B).
Figure 4
Target:
\\PX_SERVER\Rollouts\ADSK\2014\RVT_2014\x64\Img\Setup.exe /qb /I \\PX_SERVER\Rollouts\ADSK\2014\RVT_2014\x64\Img\RVT_2014.ini /language en-us
Start in:
\\PX_SERVER\Rollouts\ADSK\2014\RVT_2014\x64\Img
And given how awkward editing the target value is, I suggest two things. Make a backup copy of the shortcut just in case, and copy the contents of the Target field into a text editor (Notepad will do in this case, as will NotePad ++) to modify and copy back.
Next, we need to replace the path in the “Deployment” ini file. This is the same file we modified to address 32-bit CV++ components above, and requires two replacements in the Global MSI Properties section. You will need to revise the path in the ADMIN_IMAGE_LOCATION line, as well as NETWORK_LOG_PATH (Figure 5).
Figure 5
At this point I have a functioning relocated deployment, but if I am making copies of the deployment for other offices, things are a little more involved.
The first thing to be aware of is that you can move and copy a deployment, but you can’t (easily) rename one. The name gets encapsulated in an MST file, which is a binary file format that requires specialized tools to edit. The takeaway here is, if you want to make a single Deployment and copy it, give it a generic name such as RVT_2014, not a location-specific name such as RVT_2014_Berlin.
The last thing to be aware of is a Revit-specific issue. If you are using a “Custom” Revit.ini file that you imported into the deployment (Figure 6) and that Revit.ini has location specific pathing (maybe the template and family files have a different path in different offices) you will need to revise that Revit.ini also. Now, you could just edit the deployment in each office and load the right one, but editing a deployment has some pitfalls (see Bonus #1 below).
Figure 6
So, the quick and dirty (and better) answer is to drill down to the …Img\CustomSettings folder, where you will find a Revit.ini with the name of your deployment tacked on the front. Revise any paths here for the specific location and your deployment will install as expected with those custom settings. Note that this CustomSettings folder is for Revit 2014 and 2015. Revit 2013 wouldn’t even let you load a custom Revit.ini until SP2, I believe, and also uses a different folder, as does Revit 2012. If you are addressing deployments for older versions, you will need to do some homework, but the basic process is the same.
Bonus
1. Deployments are fragile! Editing them can cause all sorts of problems, so as a general rule, try to find alternatives to modifying deployments with the Create & modify a deployment tool.
That said, sometimes you just need to do something simple such as change the license server or serial number. In that case, edit, but be aware that editing ANYTHING reselects content. Every time. So, every single time you get into a deployment, go back to the content selection step and make sure it is off, if that is the condition you intend. Otherwise your installs will be slow and your hard drives full.
2) Revit server accelerator. When creating the deployment there is a setting for Revit Server Accelerator (Figure 7). However, in Revit 2013 and 2014 this setting is ignored, and users have had to manually assign an accelerator at first launch. This setting in the deployment just sets the value of an Environment Variable when it is working, and that can be done externally from the deployment as well.
Because this can be done externally anyway I just skip assigning an accelerator in the deployment, and then assign it via script, Group Policy, etc. post install. This makes it even easier to use a single Deployment for multiple offices, even with Revit 2012 or 2015 where the bug doesn’t exist. Who wants to make a new deployment just to point at a different RS Accelerator? The EnvironmentVariable you want is RSACCELERATOR#### with #### being the version year in question, and while you can do this either as a User or a System Environment Variable, I recommend System in most cases. This is also what the deployment setting does in those versions where it isn’t broken.
Figure 7
3) FlexLM assignment. The FlexLM setting is a little different in that it creates the LIC file that is pushed to the machine during install. However, LIC files are a VERY bad way to handle license server assignment (you can get more detail on why at my blog). A better approach is to assign License Server via System Environment Variable just like we did the Revit Server accelerator. You can then change the setting later if, for example, you need to migrate to a new FlexLM server name. The Env Var is ADSKFLEX_LICENSE_FILE, and again you want to use a System Environment Variable under most circumstances.
Also, you may come across a situation where for some users, after the uninstall of an old program, say AutoCAD® 2010 or some other program, maybe even the new version of Revit, will fail to get a license. You might not even realize that removing AutoCAD was the trigger, which makes this a rather insidious problem to troubleshoot. The key here is that the first place Revit, or any other Autodesk product, looks for a FlexLM server is a User Registry value. If that value references a LIC file from certain old programs, and that LIC file is missing, then some newer programs will fail to find the proper FlexLM server, be that in an Environment Variable or a LIC file. The solution is to delete the registry value at HKEY_CURRENT_USER\Software\Flexlm License Manager \ADSKFLEX_LICENSE_FILE, at which point the next time you launch, the data will be re-read from either the Environment Variable or the correct LIC file if you aren’t using the Environment Variable. This is a rather more detailed topic than we have space for here, but again, more detail can be found on my blog.
And with that, I hope you have a good Install Spring, and an even better User Training Summer.
