It seems Autodesk changed the way the generated installer works.
Until version 2022 it generated a setup.exe which could be launched in “silent” mode.
In version 2023 the generated setup.exe does not react on any of the known commandline args. We were unable to get it running in “silent” mode.
The process also changed for AutoCAD 2023 and it seems that for silent installation, it is now required to create a deployment and use their new “Installer.exe” to run a “deploy” action which then runs in “silent” mode.
The deployment consists of an installation image (more or less what the OEM installation wizard creates) and a special Collection.xml which contains actions for “Installer.exe”. There are references to many different kinds of GUIDs.
If our observation is true that setup.exe cannot be used directly for “silent installation” then that’s a rather important point which I would’ve expected to be communicated. The impact on supporting tooling (setup + update tech), customer support processes, documentation is significant.
I could not find any references to this rather critical element of infrastructure in any of the related documents.
Did I miss something? Does anyone know about that?
I’ve the same issue too, for my product silent install is trivial.
A workaround could be to send the parameters directly to the Autocad OEM msi but it 's more difficult and you have to manually install all the prerequisites.
Thank you Paavo,
this solves part of the issue, because the user can’t select a custom folder for the installation.
At the moment the most complete solution is to install all the prerequisites silently and then the main msi (under x64<PROGRAMNAME> subfolder):
for me the silent install from Madhu “setup.exe --silent --pf abc --sn defghijk” works fine and if you modify the setup.xml beforehand by you own installer …
c:\PolySample
… you can indirectly influence the installation path, too.
I tried it, but by changing the line in xml, you will change the previous directory:
i.e. suppose you set in setup.xml the directory as you wrote above.
All of the files of the oem will be in the directory
c:\polysample\[NAME OF PRODUCT] [YEAR OF PRODUCT]
and not directly in
c:\polysample
Probably there will be another place/xml/ini where you can change it, or specify the main program directory name, but I tried to edit both:
setup.ini
setup.xml
manifest\app.[productname and year].xml
For us this is perfectly fine as it is. We never let our customer change the folder name. He can change the path, but we always append a folder with the name of the product.
So we are expected to pass the serial number to our clients (or potential clients)?
That is a new one - and practically would make our serial number public.
It is basically what Autodesk’s web based deployment configurator does. We used that as a base, and modified all configuration files until it worked for our OEM product. It is quite involved, though. The ODIS based deployment is a bit complex to set up (various settings and GUIDs in several *.xml files, command lines have to be perfect, etc.) and the ODIS installer UI is prone to “hang” (i.e. wait for sub-process/services) if any little detail is not perfectly set up.
If the approach with “setup.exe --silent --pf … --sn …” is acceptable then I’d stick with that. That’s what we’d prefer to do though we are looking at the option to deploy the *.msi directly, too.
If you still like to know more I can post a bit more.
Thanks for your replay, but more details are no longer needed, as “setup.exe --silent --pf … --sn …” works for us. We’re using our own installer which triggers among others the AutoCAD OEM installer silently. Therefore is our serial number not public for our customers.
We are doing the same (own installer) but the serial number in the command line is visible in the task manager or even permanently in the Windows process audit log (often activated in enterprise environments).
setup.exe does not seem to care about the values passed via --pf and --sn.
Installation with “setup.exe --silent --pf 000 --sn 00000000" or even arbitrary characters seems to work.
We’ll test this in more depth.
That brings us to the next question: What is a proper way to uninstall?
Up to now we used msiexec to uninstall. But with 2023 this leaves a zombie entry in Windows “Programs & Features”.
Does anyone else have the same issue or another approach to uninstall?
We too, but our main folder name (the name that we append) is not [productname] [year] but there’s something more and in the wizard is not allowed to insert it, we usually do it with an external setup wizard and then (till the release 2022) we pass the path to the silent installer.
If you install the msi (via msiexec) you can pass INSTALLDIR.
If you use setup.exe you can in-place patch pkg.<name>.xml set the installation directory before spawning setup.exe to start the installation.
For install the previous workaround with the random serial number works good enough, wish we still had the -qb style so that the user can see something is happening but better than nothing.
As for uninstall the biggest quirk that I run into with the info from the ADN guy is that you have to retrieve the GUID for the install after you use the OEM install wizard to make the install. In my testing so far each time I do a new build with the installer it has a new GUID :(. A little bit frustrating, but at least I can make a build with silent install and uninstall. I just wish we could still have a status box come up so that the user can still see something is going on in the backround.
Hi derrick, sorry for the late reply. We were busy testing our approach.
It is very similar to the answer from ADN. We use setup.exe (which itself calls ODIS) for simplicity instead of ODIS directly. As you said, the GUID needs to be extracted and stored for uninstall.
We have our own tool similar to Autodesk Desktop App which makes storing the GUID easy enough and provides its own progress indicator. But I agree, the default OEM installer UI is a bit lacking.
Our uninstall commandline differs a bit to what’s detailed in the OEMScripts repo… Trial and error got us there.
We have run quite a few installs/uninstalls on various Windows configurations so, at the least, it seems to be stable. Will know more in 1-2 months when our customers had a chance to try it out, too.
Just to clarify to anyone who reads this. The ‘–pf’ and ‘–sn’ arguments can be arbitrary or fake, don’t use any real serial numbers for this. See full post from Madhu at the ADN here: