I'm trying to prepare the Revit 2021 hotfix (21.1.1.6, brings the program itself up to 21.1.60.25). I am testing it with the System account (via PSexec) to make sure we can push it to users via Intune. Every time I run the hotfix, it processes for one minute then exits. This is the same whether I am using /quiet or /install or both or neither.
I am able to run the file and install this hotfix manually. But something about running it as System is tripping it up. I've done tests with cleanly removing all Autodesk products and confirmed this acts the same way whether I am trying to apply it to Revit 2021 base version or 2021 with hotfix 5 applied to it. We did also make a dummy Intune app to test and make sure the behavior matched what PSexec showed us.
I've attached the logfile from the install. Its not too long, only covers 2 seconds worth of attempt. It looks like it confirms Revit is installed (version 21.1.50.27 in that attempt, which is correct), confirms the new hotfix is not present yet, confirms add-ins, sets the restore point, and briefly attempts to run. All results & error codes from that point are "0x0" which does not give much to work with.
The frustrating part is I just did this with ease for Revit 2020 (Hotfix 7) and 2022 (Hotfix 2). 2022 did change the preferred switch (-q instead of /quiet), but that was the only obstacle. The closest results I found in searching through forum posts were errors with Revit 2017 & 2019 updates (2017 post & 2019 post). Both were due to version detection issues caused by other updates. This would seem unlikely given that I can complete a manual install attempt, but I wouldn't be surprised to hear it is something similar.
Solved! Go to Solution.
Solved by brian.leeson. Go to Solution.
As a quick follow-up, a few things we have crossed off since:
Do you have any msi log files from the %temp% folder ?
If you run the update with the system account, the %temp% folder is in C:\Windows\Temp.
regards
Markus
It looks like the /log switch determines if it goes to %temp% or to a specified location, but they are they same output. I've attached a log we did this morning and let go to %temp%. It looks like a close mirror to the previous log.
We might have had a breakthrough, but not sure how to interpret this info. If we trigger the hotfix with /uninstall first, it does run through the process for a moment. Then when we try /install again (/quiet or without), it works. Current guess is something is installed that hotfix 6 thinks is its own / is a conflict. Uninstall removes whatever that is and then clears the way for install to complete.
We will do further testing and try to determine if this will cause issues. We may install it with a batch that runs /uninstall, waits, then runs /install. If anyone requests it, I can provide logs from the remove or the install.
Tests have succeeded. The closest we could find was it was some aspect of the Cloud Model part causing the conflict in the install, but cannot say for certain.
Running uninstall before install has worked for users, so accepting that as solution.
Can't find what you're looking for? Ask the community or share your knowledge.