Title says it all

The Situation

This post is way, Way, WAY overdue, and for that I know an apology doesn’t really address the issue, but I offer it anyway.

This year has been a rough one for me as much as anyone else, and more than anything I have had a massive case of tunnel vision. I started testing these new ODIS deployments in April, and running into all sorts of issues, and at the same time I was working on moving some of the Work from Home features I had planned for Px Tools 4.0 into 3.4.5. I had thought this would be a somewhat difficult proposition, but easier than waiting for Px Tools 4.0, because 4.0 is a complete refactor to use classes rather than functions, and that alone is a massive undertaking. But to make certain things work, especially the Nested Tasks feature that is foundational for dealing with both some aspects of the new Autodesk deployments as well as Work from Home scenarios, I had to at least restructure data handling internally, to make use of Dependency Injection. And this not so long after learning how DI works with classes. And I discovered that DI is pretty fundamental to Classes, but basically just glommed on to functions in PowerShell. So, I started down that road, discovered issues in the new Deployments that really would best be served with the new build of Px Tools. The I would solve a big issue with that work, after a week or two of effort, and thought “I am close, I should just finish 3.4.5 then issue recipes that make use of those new features. Then the very next week I would hit another major issue with the code, and a week or two later repeat. But I was so tunnel visions I never took a step back, looked HARD at what COULD be done with Px Tools 3.4.4, and properly answered the question “Do I really NEED to wait for 3.4.5?” Then early in December I had a couple of customers ask, basically “Where the hell are the 2022 recipes?” My emphasis, not theirs, they where both very gracious in their request for massively overdue recipes. So I tabled 3.4.5 and started the deep dive into new recipes for 2022, and there again every week was a slog, solving one problem only to find a new one immediately after. And so went December. Finally just before Christmas I thought I had all the problems solved, and I spent the week between the holidays building test recipes and testing everything, finding a few more issues that where thankfully smaller, and finally New Years Day saw all the recipes and resources finalized, tested and cleaned up for publishing. And today I have finally finished this post. And so, with the new year these recipes are finally available, I have learned a valuable lesson about questioning and testing assumptions, and after more than a month or two of struggle even questioning and testing decisions.

With apologies and explanations, or at least excuses, covered, let’s move on to what’s actually changed.

Installs

The new ODIS based deployments that Autodesk started pushing with some products for 2021 products, and adopted across the board for 2022, are a bit of a mixed bag.

One thing that is VERY welcome is the fact that ODIS deployments can be run from a local drive easily, unlike the classic deployments that expected a UNC path and thus some goofy workarounds to make them work from a local drive. ODIS deployments are also much easier to relocate, either because you change the server name or path where the deployment lives, or perhaps because you want to take your network deployment and ZIP it up for use locally in Work from Home scenarios. And you DO want to install locally, because ODIS deployments, just like classic deployments, do not like slow networks or VPNs.

I will assume for this post that everyone is familiar with creating these new deployments, and just discuss the issues related to silently installing with them.

The first thing to discuss is the command line arguments. A classic deployment uses the following very Windows standard command line arguments. You start with the full path to your executable, which is Setup.exe. /I marks it as an install, /q makes it quiet (with no UI of any kind) and Revit_2021.ini is the data file the deployment uses. All Autodesk examples will provide the full path to the INI, but a classic deployment was smart enough to look for the ini in the same folder as Setup.exe when only the file name is provided.
PATH TO… \Setup.exe /I /q Revit_2021.ini

And, for classic deployment Autodesk would provide both a shortcut and a BAT file in the SMS_SCCM scripts folder.

For an ODIS deployment there is no shortcut provided, just a BAT file in the root of the image folder, and the active line as Autodesk provides it is the manual install option, which looks like this.
“PATH TO \image\Installer.exe” -i deploy –offline_mode –ui_mode basic -o “PATH TO \image\Collection.xml” –installer_version “1.18.0.25”

As you see they have moved on from Windows standard Setup.exe based installers, and are using their own Installer.exe, which you will quickly note abandoned the Windows standard / denoted arguments and instead uses a combination of “simple” arguments with a single dash demarcation, and “complex” arguments with a double dash. –offline_mode seems like it should ensure that nothing is downloaded during install, but you will find that stuff DOES still get downloaded (to C:\Autodesk\WI). At a minimum the ODIS Installer itself is constantly being updated and new versions downloaded. This CAN mean that the behavior of a deployment this week will be different from the same deployment in 6 months, due to changes in the ODIS installer itself, and that may lead to some interesting troubleshooting in time. –ui_mode basic defines the standard install procedure that requires user interaction. The -o argument & Collection.xml file replaces the ini used in classic deployments, and here the full path MUST be provided, ODIS isn’t smart enough to find the file, even though like the classic ini it is found in the same folder as the executable. Finally, there is the —installer_version, which I am assured by Autodesk is important to include, though I had no issues not including it in months of testing. I am hoping to get some clarity from Autodesk on this, but for now Px Tools users need to note that downloaded recipes will need to be updated with the actual installer version number found here, since this will change depending on when you actually create your deployments.

Again, it just takes a simple change to make it silent, and we find that info in the remarked out line in the BAT file below the one discussed above. The change is simply to replace –ui_mode basic with -q.

One thing to note about the BAT file, it provides ZERO information about success or failure of the install. When combined with the fact that BAT is the technology equivalent of rubbing two sticks together to make fire, I suspect lots of people will NOT be using this install method for silent installs.

The other ODIS deployment issue to be aware of is the “lightweight” deployments of things like DWG TrueView and Navisworks Freedom. Here you download an exe that unpacks to C:\Autodesk, and that folder IS the deployment. You can copy that to your network and then use that path, this time to Setup.exe for some reason, and -i install -q as your arguments. Exactly what the difference is between deploy and install, I don’t know, but here is where you see the differentiation.

A final note on installing with the deployments themselves, with classic deployments you very much needed to include /norestart as an argument, so you could gang together a bunch of installs and then handle the required restart yourself at the end. Autodesk says nothing about this, and in all my testing without this argument I never saw a restart triggered, but despite this argument using the old / argument indicator, it seems to work, or at least not cause a failure, so I have been including it as a bit of insurance. I hope to get some clarity from Autodesk in the new year.

Another thing to be aware of with ODIS deployments is the change in logging behavior. Classic deployments by default would put a single log for every install of a particular product in the log folder of the deployment itself. This log would include lots of details that are only of interest to Autodesk, and so could be problematic for those of us in the trances to review. And the fact that every machine that installed a particular product would be appended to the one massive file made this even more difficult. the latter issue could be mediated by changing the path to the log to include %ComputerName% to end up with an independent file for each machine as well.
ODIS changes all of this. There is still a log file in the deployment, and it is still a running log for every machine that installs that product, and ODIS will NOT allow us to break this up by machine with an environment variable reference. Not that it matters since the information in this file is little more than the name of the sub installs and when they started. No information at all about failure or success. That information is now found on the machine, and in AppData Local for the installing user. Specifically in the C:\Users\USERNAME\AppData\Local\Autodesk\ODIS folder.
And the log is a collective log for every piece of software installed on the machine, with even more detail intelligible only to Autodesk. In fact, it’s not even a single log file. After just a few installs on a test VM I have 8 different DDA.log files of well over 10,000 KB each, an Install.log of nearly 4,000 KB and 20 other files of various sizes. only the Install.log is of any use to us, but it is formatted in a VERY non human readable way, with single lines that are hundreds of thousands of characters long. Basically, these logs are of little use to use, and they are so huge that Autodesk asks us to delete the entire folder before each and every install, and only send the zipped folder for a single install. But they give us no mechanism TO handle that. And this is a logging system they only invented in the last few years. It’s bad enough when they design some new system that sucks for us, but to design one that sucks for them too? I just don’t understand that though process.
In any case, I am sure we will learn over time how to extract data from these logs. I am certainly playing with some PowerShell to extract meaningful info, once I figure how to identify that info. But that is a project for after Px Tools 3.4.5 is out, and a side project for when Px Tools 4.0 work is getting on my nerves. We shall see when I finish that.

Finally, we need to discuss updates, and on this front ODIS installers are a huge improvement. With the exception of 3D Studio Max, I am finding that every single update, across the entire product line, uses a single consistent set of arguments. This alone is a massive improvement over the hodgepodge of argument sets we have previously. For these updates you download the EXE and use -q /norestart for your arguments.

Max is different in that updates are NOT a patch, they are basically full installs. Every single file is replaced, so they are massive. And they are handled very similarly DWG TrueView and NavisWorks Freedom, with -i install -q /norestart as your arguments. Max has some other issues to be aware of, but we will get to that in in a moment.

With that, lets move on to Uninstalls.

Uninstalls

The first thing to be aware of is that (of COURSE) ODIS based installers introduce a new uninstall mechanism as well.

The classic installer used the standard Windows uninstall process, where the installer creates a GUID key in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall (or HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall for 32 bit software installed on 64 bit Windows, i.e. Autodesk Material Libraries)

This GUID key would include various properties, but the pertinent info for our purposes is DisplayName, DisplayVersion and UninstallString. For example, Revit 2021;
{7346B4A0-2100-0510-0000-705C0D862004}
DisplayName = Revit 2021
DisplayVersion = 21.0.0.383
UninstallString = MsiExec.exe /X{7346B4A0-2100-0510-0000-705C0D862004}

That UninstallString isn’t a silent uninstall, but simply adding /q to the end is all you need.

ODIS installers will create the same GUID keys, as seen here for Revit. And in most cases you can successfully uninstall the old school way.
{7346B4A0-2200-0510-0000-705C0D862004}
DisplayName = Revit 2022
DisplayVersion = 22.0.2.392
UninstallString = MsiExec.exe /X{7346B4A0-2200-0510-0000-705C0D862004}

However, there will be an additional GUID, with a slightly different DisplayName, and a VERY different UninstallString.
{03BD6A4A-C858-3AD2-9353-DF2974C9918B}
DisplayName = Autodesk Revit 2022
DisplayVersion = 22.0.2.392
UninstallString = C:\Program Files\Autodesk\AdODIS\V1\Installer.exe -i uninstall –trigger_point system -m C:\ProgramData\Autodesk\ODIS\metadata\{03BD6A4A-C858-3AD2-9353-DF2974C9918B}\bundleManifest.xml -x C:\ProgramData\Autodesk\ODIS\metadata\{03BD6A4A-C858-3AD2-9353-DF2974C9918B}\SetupRes\manifest.xsd

This uninstall string also simply needs -q added to make it silent, just like with the install. The fact that the full path for both the XML and XSD files is as unfortunate as the similar situation with ODIS installs.

With instantiating an ODIS uninstall covered, now let’s talk about what they do differently and why you want to use them.

New Uninstall Behaviors

These ODIS based uninstalls introduce two new behaviors with a lot of potential. First, this is a batch uninstaller. Rather than needing to track down the GUID of every component that gets installed, the ODIS uninstaller will handle much of this for you.

For my test install of Revit I found all of these separate uninstalls where handled by ODIS.
Autodesk Cloud Models for Revit 2022
Autodesk Revit 2022
Autodesk Revit Content Core 2022
Autodesk Revit Content Core-RVT 2022
Autodesk Revit Product Feedback 2022
FormIt Converter for Revit 2022
Generative Design For Revit
Personal Accelerator for Revit
Results Explorer Manager
Revit 2022
REX Framework
REX Revit
RSA COM
RSA CommonData
RSA Interop
RSA RoReinf

The thing you will notice is that this includes both core functionality, like the RSA components, as well as addins like Formit Converter. Thankfully, you can still handle Addins independently, i.e. uninstall JUST something like eTransmit because you are upgrading to a 3rd party tool and don’t want to leave the “wrong” way to do it installed. You use the traditional MsiExec uninstall approach in this case, it seems like all addins do work, and doing so does not cause the ODIS uninstall to fail later.

More concerning is the fact that not everything you might expect IS included. Again, using Revit as the example, you would expect OpenStudio CLI For Revit 2022 to be part of the ODIS uninstall, but it is not. AutoCAD and AutoCAD Architecture leave behind AutoCAD Open in Desktop, Autodesk App Manager & Autodesk Featured Apps for us to deal with the old way, but AutoCAD MEP leaves those three behind as well as the base AutoCAD 2002 (but interestingly NOT the associated language pack), two AutoCAD Architecture components (Core and Shared) as well as AutoCAD MEP Core, and only an AutoCAD Update in my testing. And this is odd, because there is no REASON why there should be a GUID associated with an update like this (more on this in a moment), and both AutoCAD and AutoCAD Architecture do manage to clean up these extraneous registry bits, even the AutoCAD parts that form the basis of AutoCAD Architecture. All of which I hope is just a sign of youthful uninstaller that will mature with time. In the meantime, we will just need to keep track of what doesn’t get uninstalled by these new uninstallers and do that ourselves.

The other new behavior is reference counting of shared components. In theory, when a component is shared by multiple products, only uninstalling the last product uninstalls the shared component. Which would rock, if it worked completely and consistently. But there are some issues here.
First off, the 10 thousand pound gorilla of shared components is of course Material Libraries, of which there are many and what program uses what library is a mess. Having the Autodesk uninstall manage this would be HUGE in my book, but alas Material Libraries are completely ignored by the ODIS uninstall.
Another shared comment that is ignored is Autodesk Revit Unit Schemas 2022, which is shared by Max, Navisworks and Revit, and is not reference counted, so we run the risk of either uninstalling it while something dependent on it remains on the machine, or failing to uninstall it when the last dependent product is removed. You know, the same problem we have now with Material Libraries. In any case, we will also need to continue managing these shared components the old fashioned way as well.

But there is another issue with reference counting to be aware of. Two things that are reference counted are AGS (Autodesk Genuine Service) and SSO (Single Sign On), which are shared by basically every Autodesk product, even the free ones. The thing is, the Autodesk uninstaller for AGS is too stupid to stop the process before uninstalling. So the “last” Autodesk product uninstalled from a machine will ALWAYS piss the bed with error code 1603. Because I do my testing on independent VM images, to make finding orphaned installs, reg keys and folders a bit easier, every test I ran was a final Autodesk uninstall, and every one failed with a 1603 error. And tracking down what was failing and why in the new logs was a real pain.
Once I realized this was what was happening, and started doing 100% of my uninstall tests with something else installed (usually just Navisworks Freedom) those 1603 errors went away. This doesn’t affect most people now, as if you ARE getting rid of every single Autodesk product, and are keeping the machine for some other use, you are likely to be reinstalling Windows anyway, and not actually uninstalling anything. But the nested task capability in Px Tools 3.4.5 will allow us to kill that process before every ODIS uninstall so it CAN succeed if it’s the final product. Hopefully the flat spot on my forehead from banging my head against that wall will eventually heal. And hopefully the next time Autodesk throws that kind of curve ball at me I will figure it out a little sooner.

Revit Unit Schemas brings up another new “behavior”, this time by Autodesk themselves, and not a good one. Windows best practice for installers is to NOT create a new GUID unless things can be installed side by side. So Revit 2022 gets a different GUID than Revit 2021, while Revit 2022.1 uses the same GUID as Revit 2022.0. However, Autodesk is now sometimes using new GUIDs with simple updates, and Revit Unit Schemas is one such case. Navisworks Manage & Simulate will both install build 22.0.1.367 with a GUID of {CDCC6F31-2022-4900-8E9B-D562B70697B6}, but a following Revit 2022 install will replace that with build 22.0.2.392 and GUID of {CDCC6F31-2022-4901-8E9B-D562B70697B6}. And each Revit update after that (as tested so far) will continue to update this component, with a new GUID every time. And even if you don’t have Revit on the machine, Max 2022.1, .2 or .3 will also install that 22.0.2.392 build. So for all three of these products, we need to track what the latest installed build is, to know what GUID is correct for our old school uninstall. Ugly. For Px Tools users you can simply include Uninstall tasks for each GUID and accept logs that include multiple “Program not installed” messages along with one for whatever was there to uninstall. That it, until Px Tools 3.4.5 that provides a better solution.

Finally this brings us to the real problem child for 2022; 3D Studio Max. Every one of those updates for Max is a full install and a new GUID, so we need to keep track of that over time and maintain our uninstall data accordingly. If you do uninstall with the wrong GUID, you get an error code of 7, a very non Windows error code, that Autodesk doesn’t provide a lookup for that I have found. This explains the rather ugly batch of remarked out Uninstall tasks you will find in the Px Tools recipe for Max. Those uninstalls also are flagged as Terminating, so a failure due to wrong GUID doesn’t continue with all the related old school uninstalls and leave you with a broken Max in the meantime. The fact that Uninstall doesn’t default to Terminating is a sign of how rock solid Windows uninstalls have been. ODIS uninstalls are a bit of a regression here.

Lastly it is worth mentioning the Install BAT file in the deployment. In addition to the install line mentioned earlier, there will also be a rem’d out uninstall line.

rem ========== Uninstall Autodesk Revit 2022
rem “\\px\Rollouts\ADSK\2022\Revit_2022\Deployment\Revit_2022\image\Installer.exe” -i uninstall -q –manifest “\\px\Rollouts\ADSK\2022\Revit_2022\Deployment\Revit_2022\image\RVT_2022_en-US\setup.xml”

This will also uninstall Revit, and so far as I can tell exactly the same as the GUID based uninstall, but it depends on the presence of the deployment, and especially in Work from Home scenarios, that is problematic. Thankfully Autodesk does give us a consistent 100% local uninstall procedure, so long as you have the correct GUID, and that is what all the PxTools recipes are built upon.

And that brings us to some Px Tools 3.4.5 info.

Px Tools 3.4.5

Now that these 2022 recipes are posted, I am back on a Px Tools 3.4.5 focus, with the plan to get this finished and out as soon as possible, to address some of these ODIS issues. With some luck I REALLY am getting close on this. Sigh.

But in any case, the new features in 3.4.5 that most impact managing ODIS based programs includes…

A new GUID lookup capability, so you can provide the DisplayName in the Uninstall task rather than the actual GUID (actually Uninstall_Ex, all this new functionality is limited to experimental tasks). Px Tools will then find the GUID that matches that DisplayName and populate a [Task~GUID] token, which you can include in your arguments. This addresses the GUID issues with Revit Unit Schemas, as well as Max, in a single task, and makes all GUID based Uninstalls a little more readable in the XML as well.

Fully implemented Nested Tasks, both Pre and Post main task. This helps to address a number of issues, but specifically the Log files mess in these new ODIS deployments.

And lastly, Px Tools 3.4.5 has a first pass at addressing the Work from Home problem, by implementing the ability to download a ZIP file of a complete deployment, from your own servers of from an AWS S3 bucket, unzip that file to a standard location, delete the ZIP file to free up space, then proceed to run the local install, and upon completion ZIP up any error logs if needed before deleting those logs and the whole deployment, to again free up space before the next install proceeds. There are some issues with this approach, and I’ll post about that soon, but it will give us a start dealing with this, until Px Tools 4.0 gives us a much more complete mechanism.

And so, to wrap this up, this post is going live in the evening of 2 January my time, and I will then start adding links for 2022 resources and recipes, and then adding update tasks. That last may happen on Monday, along with starting to get independent addin definitions posted. Hopefully this information is helpful, and again my apologies for letting this take so long. Lesson learned and it will not happen again.