New School Deployments: 3DS Max 2021 & stalled install automation

Autodesk is transitioning to a new approach to Deployments (hereafter referred to as “new school”), and there are some issues to be aware of. For those of us in AEC 3D Studio Max is where this comes up, so let’s look at it.

Many offices use a PowerShell based automation to manage software installs and updates. PowerShell is Microsoft’s platform for server and workstation management and replaces the old, less capable and less secure BAT and VBS based approaches. But Autodesk only provides BAT based examples of automation in their Deployments, both “new school” and “old school”. So, my first step when trying to get a 3DS Max recipe working in Px Tools was to translate the Autodesk provided BAT file to a PS1 script, using the standard Start-Process cmdlet with the -wait option. And here I started seeing some unwanted behavior.
We need that -wait option because Windows can only handle one install at a time, so we need to start an install (a deployment, and standalone install, and update install, whatever) and wait for it to complete before starting the next one. But in lots of my tests the Max deployment would stall. CPU, network and disk activity would all drop to zero, Max would be there, installed and ready to go, but control never came back to my script. So, any en masse installs that include Max would die. A reboot and restart of the automation would always work the second time, but that requires a manual interaction with every single machine and is not a viable answer.

I have been testing this to death, and my conclusion is that this is an odd interaction between Powershell, specifically Powershell 5.1 and Start-Process -wait, and how Autodesk is installing Desktop App in the new Deployments. It seems that Autodesk is not only creating the Desktop App service and setting it to start automatically, it is discretely launching the Desktop App process as well. This becomes an issue because PowerShell 5.1 changes the way child processes are tracked with regards to the -wait option. Basically EVERYTHING that is started by the process started with Start-Process is waited for. Since the deployment starts the Desktop App process, PowerShell is waiting till Desktop App “completes” to return control to the script. I have verified this by waiting till my script has stalled, then killing the Desktop App process in Task Manager. Within a few seconds of doing that, the script continues. I have also verified that this is unique to PowerShell 5.1 (and perhaps later) since Windows 7 VMs with PS2.0, 3.0 and 5.0 do not show this behavior, but upgrading PowerShell to 5.1 causes the behavior to manifest.
This is an odd combination of Autodesk Deployment and Microsoft Powershell behaviors, but something we all need to be aware of, since Powershell 5.1 is the default on Windows 10 machines, and Autodesk is moving everything to the “new school” deployments eventually.

All of this is also unnecessary (it seems to me) because Autodesk already handles AGS (Autodesk Genuine Service) correctly; install the service set to launch automatically and then LET it launch automatically. Then it never becomes a child process of the deployment process, so we aren’t waiting for it to “complete”. But Autodesk hasn’t done it that way, so we need to find a solution. Thankfully, Desktop App is something that really shouldn’t be getting installed anyway since it depends on the user being a local admin and that is poor security hygiene. And users should be focused on billable work, not software updates, anyway. So, removing Desktop App from the deployment solves multiple problems. And if you have read my post on Revit 2021 content in deployments, you have a sense of where this is going. But the “new school” deployments change the details dramatically.

Start by going to the image folder in your deployment, then to the {GUID} named folder (your GUID will be unique to your deployment), and finally the manifest folder. Here you will find the app.RVT.xml file that defines some of what is getting installed by this deployment.
Manifest location

Edit the file in your preferred XML editor and look towards the bottom of the node for Autodesk Desktop App. Remark this out (in XML that’s wrapping the node in <!– and –> ) and your deployment should work as expected when automated with PowerShell.
Manifest revision

There are a LOT of other things going on in these “new school” deployments, and as I get my head around what is happening and what is possible from a deployment customization standpoint, I’ll be doing more of these posts. I expect it will turn into (at least) a small series at some point. Uninstalls especially look to be new, and problematic, as well; so we’ll cover that as I get my head around it also.

Until then, I hope this saves some frustration. Stay healthy! And wear a mask! 😷

Comments