Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

With Jira Assets Discovery, for agent installs on NEW servers we get "Unhealthy" token errors.

michael.caruso July 8, 2025

We are deploying windows agents using the script provided in the KB article:

https://confluence.atlassian.com/jirakb/how-to-deploy-assets-discovery-agents-through-software-deployment-1528209363.html


However, in our case, these are being deployed on machines that have not had the agent before. We are noticing that upon deployment approximately 30-40% of agents report back as having invalid/unhealthy tokens, the other 60-70% are fine. These are deployed using the same script, many on the same subnet as those that work without issue. Given that we are getting an “Unhealthy” error message, there is communication taking place and we have ruled out firewall issues. We find that if we do an initial revocation of the token, some machines then report back in with valid tokens, but this happens for less than 1% of the affected machines. For the others, we find that if uninstall the client and reinstall multiple times, manually deleting files and restarting the machines, that this resolves the issue  for about 80% of the affected machines. The other machines still seem to fail to acknowledge the tokens.  

What is confounding is that as stated above, multiple reinstalls of the agents, manually deleting installation folders, sometimes works right away, other times, works after a number of attempts.  We cannot seem to find a pattern to the problem or even the seemingly random resolution. We wanted to see if anyone else has encountered this issue. 

1 answer

0 votes
michael.caruso July 16, 2025

As a follow up we have noticed that if we delete the .bak as well as the cfg file, this resolves issues with some of the problematic clients. Initially we attempted to edit the .cfg file and blank out the token string there and we noticed 2 things. First that we needed to reset permissions on that file to allow the svc account that was running the automated deployment of the client read write access. Removing the .bak file was also critical as the old "bad" token string would return. 

We are still trying to work through why the last few clients are still giving us issues. Not sure if we are somehow missing steps with them or not. 

One thing I forgot to mention in my original post was that, for any client that has an "unhealthy" token message, while not an intuitive thing to do, you should "revoke" that token. That is because there may be a local record on the server that may not match. Not sure why, but this did resolve the issue for 1-2 of the clients. I assume somehow the initial attempt created some entry on the server that needed to be removed server side.

Nonetheless, still working through the rest of the clients to see if deletion of the .cfg and the .bak files along with revoking the token on the server is the ultimate solution to this. 

Jacob Haskamp July 31, 2025

We have the same issue, to add on to this another thing was deploying .NET v4.2.7 on some of the Windows machines fixed a few of them.

Any further progress on your end with resolving the rest of them? We seem to get this more on laptops and Windows 2k16 servers, otherwise no identifiable pattern has emerged yet. 

michael.caruso July 31, 2025

Its been tough identifying patterns with this issue. 

This week we sort of came up with a fix. We found that even when we re-issued the token, that the old value would get restored from the config backup file, we also noticed that write permissions on those files (.bak and .cfg) files were strangely read only on the affected machines.  Ultimately we wrote a script that: 

  1. Stopped the discovery agent service
  2. Deleted the .cfg .bak files
  3. Restarted the service
  4. Reissued the token

This seemed to work. However, there were a couple of stubborn ones after that that we did eventually get working. We noticed that even an uninstall does not remove all of the files. So for the remaining ones we wrote a script that:

  1. Uninstalled the agent and the service.
  2. Manually deleted the directories
  3. Reinstalled the service
  4. Re-initialized the token.

So overall, we are still trying to get a better sense of root/cause. I think it may have been a combination of possibly deploying too many agents at once and overwhelming the server combined with the .bak file wanting to restore even after a new token was issued.

We just got this working this week,  yesterday really. But it’s taken weeks to get to even that point.  The error logs that were thrown were not helpful. They referenced some issue that had us going down a rabbit hole with regard to possible GPO encryption issues. But the above steps seemed to eventually work. The real question now is, what would the root cause be and why does the fix not work initially on all machines, yet seems to work if we re-run it.

Also one other thing to remember was that its good to “revoke” the token on the server even when they are showing as bad as this removes the entry for that token on the server side only. We found in a few cases, that this resolved the issue as newly seeded tokens were not initializing as the server thought it already had a token for it. So one other thing we now do, is that whenever we see this issue, the first thing we do, is revoke the bad tokens and check one more time.

 

Jacob Haskamp July 31, 2025

Thanks! I'll be giving that a shot actually.

I did do some wireshark digging and it appears to be the agent itself, the token being sent between the client and server appears to be reverting back to the original on the agent - for some reason. 

To be more descript:

On the first “Refresh”, the server sees the old token and asks the agent to update via sending a cmd "(.UPDATE_TOKEN)".

The agent “sends” the new token blob and the server replies with a clean ".BYE.."

After that, the server never asks for an update again—it’s still holding onto the new token hash (you can see it if you decode the file). But then when you refresh the server - after triggering a scan or something changes on the client - the client will send back the original token code.

Now I still think the only solution is a full reinstall of the application & wiping the files like you did. I'm still unsure what's causing that behavior however. If I find a root cause I'll followup this post, thusfar it appears to not be a bug in the application though and more something Windows related. 

 

Oh well. 

 

Jacob Haskamp July 31, 2025

Small update, but I ran Process Monitor - Sysinternals | Microsoft Learn and saw the service account we were using could not write to the files in the directory for the agent service, along with REG Key Errors. 

I granted the account Read/Write to that directory - and this fixed our issue

michael.caruso August 1, 2025

We noticed the same thing too. For us it was a combination of setting write permissions on that directory and deleting the files. At first, we were only setting the write permissions, but we noticed the files would come back until we deleted the .bak and .cfg files. 

Even with that , for us, sometimes we have to do that 2-3 times before it works. So strange. 

Which reg key errors were you seeing? 

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
PREMIUM
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events