Fusion Lab Installer Not Completing (Fusion Admin Install.exe)

[EduITAdm]

I am having difficulty getting the Fusion admin installer to complete.

I can see that it starts, then fires up the streamer. C:\Program Files\Autodesk\webdeploy gets created, and the production folder fills with the latest version of fusion. However, the desktop icon appears and then disappears. Even though it seems to be installed, it cannot be launched because the fusionlauncher.exe.ini file contains: "This is a place-holder file which is intended to be updated by the streamer."

So it seems like the install tanks right at the end. I am unable to locate a log file generated by Fusion Admin Install.exe.

This installer is running via the system account, so I would expect the log file to appear in c:\windows\temp but I am not finding it there.

Any clues on where I should be looking for that?

[EDIT] Found it at C:\Windows\System32\config\systemprofile\AppData\Local\Autodesk

Attached to post

[EduITAdm]

I have verified that the installer will not work if run by the machine's system account. So, this software is no longer deployable with a software management system like Microsoft Endpoint Configuration Manager. This also means the scheduled tasks I create to regularly update the software will fail, as they also run via the system account. The lab installer for Fusion 360 worked fine.

[EduITAdm]

Just in case anyone else comes across this issue. I have seen it with other products that use Java or Python scripts during installation. The only way I have found around this is to use scripts for installation and removal that do the following.

1.  Create a random password.
2. Create an administrator account using password from number 1.
3. Leverage psexec to launch the installer as the account created in #2
4. When installer is finished, delete user account created in #2
5. Delete profile folder for user created in #2.

This is speculation based on observation, but I first encountered this issue when we were still a mixed Win7 & Win10 environment. Installers that worked fine on Windows 7 when executed by the system account would fail on Win10. They were always using Java or Python. In digging in the logs, the installers would often fail when attempting to allocate memory for the JVM. So all I can guess is that there is some sort of memory restriction for the system account that locally logged-on users do not encounter. If anyone knows another way around this or perhaps a Windows security restriction that I can modify to avoid this, please share.

So far, I have needed to use this method for Anaconda, Labview, TensorFlow, Intel ProSet Wireless Profiles Installer, and JMARS.

[Austen.ewaldRQYLE]

Yep I'm having this same issue with the latest update. Working on a solution so far nothing has worked out yet. Support has been less than helpful with this matter. 

[EduITAdm]

@Austen.ewaldRQYLE 

So far, on my test machines, I am getting successful installation and removal via the method I mentioned above. The challenge is that many enterprise AV solutions will tag psexec as an issue and interfere with it, so it requires a lot of explanation to the security folks. I have also found it necessary to kill the adpclient service before running the installer. Otherwise, I get mixed results.

This is so annoying. I am afraid we will keep seeing more and more app vendors roll their own installers with Java and Python rather than pay for proven installer technologies like Installshield. I do not have the time or resolve to chase down with Microsoft what they did to Windows 10+ that caused this issue, but I feel it has to do with security hardening.

[Austen.ewaldRQYLE]

@EduITAdm 

Yea, I'd prefer not to use PSexe for a few reasons as I am also one of those security folks 🙂 Good to know about killing the adpclient service I'll keep that in mind! 

[rhitsupport]

We've run into the same problem, and installing software via PSexe and alike just seems like a security risk in this day and age. I'm struggling to see what option Autodesk want us to use? The streaming method is going to mean every machine is downloading the latest update! We just don't have the bandwidth for this.

[EduITAdm]

@rhitsupport 

Using the streaming installer has the exact same issue as well.

It still leverages Python to do the installation, so it also fails when run via the system account.

It would be nice if someone with a top-tier Microsoft account had this same issue and found this thread. They could open a support ticket with Microsoft to see if there is a way to enable the System account to work with these scripting-based installers. It costs us money to open a ticket. However, IME, that ticket would likely go nowhere. I think that the programmers at Autodesk might have more clout and connections to find a solution than us end-users.

I tried a lot of different methods, and running these sorts of installers from an interactive user session was the only thing I found that worked.

PSExec is just a tool. Like many apps in the system32 folder, it is only dangerous on an unsecured system. The only way I can imagine you can do this without it is to use a domain admin or local admin service account and create scheduled tasks that run it as that user. I would argue that having a stagnant local admin account would be more dangerous than using Psexec.

Security exceptions for PSexec can be crafted to limit the threat profile to a minimal level.

[gsofting]

I wasted a lot of time troubleshooting this issue. This made automation without opening security holes pretty much impossible to either deploy new versions or update old versions.

[EduITAdm]

Hey, at least someone inside Autodesk got a big pat on the back for saving them money by rolling their own Python-based installer. Maybe they even got a bonus! 

Meanwhile, we IT admins are left with the results.

I can only guess that this is what happens when the people making the installers never actually worked deploying software in a managed environment.

[Austen.ewaldRQYLE]

Hope you all are having better luck with support because this is currently where I'm at now and I honestly can't even begin to understand this thought process. Extremely frustrated with Autodesk currently. 

[kellings]

@EduITAdm @Austen.ewaldRQYLE I didn't want to say anything until I knew a bit more information. This issue is currently being reviewed by senior engineers from Autodesk. I'm just waiting to hear back from them, or they may potentially reply here when they have more information on the issue. 

Thanks,
Kevin

[EduITAdm]

I have had similar interactions with email education support. They're geared solely at dealing with end users and not IT administrators. My only relief has been when someone from Autodesk steps in and escalates the issue internally. Which appears to have happened 

[EduITAdm]

Thanks @kelings
I'm afraid the way around this is to rethink the installer from scratch or use those developer connections you guys have with Microsoft to find out what changed in Windows that prevents Python and Java from running properly under the system account. I hope the go for the latter and find a way around this issue rather than abandoning the Python work.

[kellings]

@EduITAdm I don’t work for Autodesk. Just want to be clear about that. Though I do work with Autodesk and get direct access to people that can help. 

I think they are starting to narrow down on the issue, but I can’t provide any technical input. Just report back what the very qualified engineering staff report back to me. 

Thanks,

Kevin 

[gsofting]

What a wild reply. There is a ton of official Autodesk documentation out there for deploying and maintaining Autodesk Fusion in a lab environment. Not to mention a standalone offline installer that is specifically for installing for all users on a PC and they say their stance is to not support it? I know the K-12 Education sector isn't a priority but we can't be the only users trying to deploy and maintain their software with software deployment solutions.

[it_btull]

We've been having this same issue. Only started happening with the latest "Fusion Admin Install.exe" (version 18719.2.0). Even on a clean install, with no previous version(s), the install will create the standard "6a0c9 . . . ." folder, then the new version "b622a . . . ." folder. The "b622a . . . ." houses 584 items when complete, but quickly after that 10 items are removed, including the "Fusion360.exe." All works perfectly fine running with a normal Local Admin account, or even when running from an Admin CMD window, but not when deployed through, in our case, MECM. 

[dan.banach]

Hi @gsofting 

Can you clarify what you are referencing when you say that Autodesk is not supporting it? If you're referring to the screen capture in the above post, it states that only profiles that are set to IT Admin can access the lab install version. 

In regards to your comment "K-12 Education sector isn't a priority", Autodesk has made a huge investment in the education market by giving many of our software title to schools and students for free for many years. We are always looking for ways to make our processes smoother.

In regards to the install issue, as Kevin stated, we engaged our engineering team to see what may have changed. We are working on it.

Thanks,

-Dan

[ifte_steinmann]

Thanks @EduITAdm for all the useful information. I can confirm the behaviour.

For some of my machines it worked to just copy the correct „FusionLauncher.exe.ini“ in the production folder after the installation stopped with the system account. Unfortunately this did not work for all machines.

So I spend my day running around the lab and manually starting the installer as an admin user on all machines to fix the broken installations afterwords.

I would also very much appreciate it if this issue could be fixed by Autodesk. The emergency solution suggested in the thread, even if it works, also seems very complicated and unsafe to me.

[dan.banach]

Hi @ifte_steinmann @EduITAdm @it_btull @gsofting @kellings 
Our engineering team looked into the Fusion lab install issue and confirmed that there is an issue when deploying Fusion through system account. The team will be discussing this issue further.

In the meantime, the solution is to deploy Fusion with an admin account.

Please let us know if this works for you.

Thanks for your help in identifying this issue.

-Dan