Flame 2025, ADSK Identity Manager and HPAnyware

We just installed 2025 on a machine to start kicking the wheels and update our hooks and noticed something very annoying with the new licensing method (adskidentitymanager). When you use HPAnyware it logs you in automatically which seems to not allow the licensing manager to set the credentials in your keyring meaning you have to login every single time you start Flame (at least that’s why it would seem like is happening).

You crash, login. You exit and restart login. Over and over again.

Has anyone else noticed this or figured out a workaround?

Hey Kyle. Not sure if this will help you, but our workaround has been to launch Chrome or whatever the default browser is before launching Flame.

I’ll give that a try, thanks.

We’re also running into this issue since installing Flame 2025 on Rocky Linux.

We’re able to work around it by doing the browser dance, but we have to repeat those steps every time we launch Flame. It also affects previous versions of Flame, too.

The Autodesk troubleshooting page says to disable Auto-Login, but we have it enabled for HP Anyware/Teradici. I disabled it temporarily, logged out/in, and it appeared to solve the issue, but the problem returned when I turned auto-login back on.

I created a support ticket but the first response wasn’t terribly helpful:

Any solution or a better workaround is appreciated. :+1:

Seems you went to the generic ADSK support which is offshore and has no understanding of what Flame is. ONLY submit tickets to the Flame support team with ADSK.

Thanks @ALan

I open plenty of Flame support tickets every week and thought I was familiar enough with the process, but aparently not. :joy: I just opened another ticket that should go to the Flame team this time.

I hope this is helpful in your efforts. I have been investigating this issue and after some troubleshooting, I have not had to log in again since making the below changes. The functionality appears to persist after reboots and logouts. I am able to launch and license Flame without the keyring message after performing these steps:

  • Remove files in ~/.local/share/keyrings/
    • I would recommend to move the files rather than rm
  • Disable the following settings under Firefox:
    • Block dangerous and deceptive content.
    • Query OCSP responder servers to confirm the current validity of certificates.
  • Choose Custom protections under Firefox settings instead of strict or standard and untick the boxes under this item.

When prompted to create a new Keyring, leave the values blank and continue.

Note The above steps may not all be necessary, but this was my troubleshooting process.

This allows me to keep AutoLogin enabled, use a remote solution, and avoid encountering the keyring message mentioned above. This is not an official solution and has only been tested on 1 instance of the issue, so remember to backup files and proceed with caution if using this process. Have a great weekend.

2 Likes

Amazing, thank you. Looking forward to giving it a go.

1 Like

To be transparent, while this workaround was effective for my system, I have been informed by another member of the Flame community that this solution is not working for their system. I will spend some time looking over the issue again after a system rebuild.

1 Like

It seems like this is pretty much exactly what we are experiencing.

The knock on effect for us is that 50% of the time (when clicking through the error) the project window is completely unresponsive and we need to terminate the flame shell window.

unfortunately leaving a blank keyring password doesn’t work in our case as the keyring remains locked after a new sign in. Additionally we can’t use auto login as these are floating systems that are authenticated through sssd so we’re a little stuck!

We’re also seeing an unresponsive Flame project selection screen periodically across multiple systems. We have to kill the process or close the shell to crash out. It usually works fine after launching again. I haven’t been able to reproduce the issue on demand and I hadn’t considered it may be related to this licensing issue.

Project startup delays can also be related to background services.
Sometimes, if you have multiple flame family workstations there can be delays, errors and even crashes while attempting to discover or communicate with remote framestores.
This is problematic if you have multiple versions of the software, if multicast has been disabled (go choke your sysadmin/engineer friends) or if someone helpfully changed UUIDs while installing software because they didn’t know that you might be able to keep backups of that kind of information.
There is not one bulletproof solution - and if someone tells you that there is, they’re not being entirely honest with you.

Guys, we are having this issue too, even without access via Teradici.

Case ID: 22335292

1 Like

Hi Phil,

The issue being discussed here is directly related to some new licensing workflows instigated with 2025. This issue isn’t a delay, but a complete inability to interact with the Project selection window. The only solution we’ve found is to switch to the terminal window spawned by Flame, and to Ctrl-C kill it. Start Flame again, and usually things are back to normal.

Anyone found a fix or a workaround yet?

Contact support with the case number.

I described our work around in the above post.

This has been consistently working for me. after login (assuming you don’t use your linux keychain for anything but this licensing nonsense) , use the command.

echo “” | gnome-keyring-daemon --replace --unlock
launch Flame it’ll probably ask you to sign in again, if that command is run at the beginning of every login (after the first time) before I run Flame, I’m not asked to log in anymore. Not sure if it’s helpful or not.