The 169.254.x.x ip is usually called as APIPA.
It could be that the server is not communicating properly in this Multi-App configuration. You can probably try:
1. Re-start the Appserver services (4th only) and the RSCD.
2. Make sure the 4th App Server is licensed.
3. Remove and re-add the server to the Infrastructure Management > Application Servers
Also, check if the hostname of the 4th app server is listed in the hosts file of this main app server.
All app servers have been restarted multiple times (and even rebooted completely) several times in the last months and this always came back the same, so I don't think it's that. There is no license in 8.5 (no need to license agents anymore), and the deployment seems to be fine too. Before I try to remove it and re-add it, I would need to make sure this is what I need to do, and not just take a guess it may fix it, so I won't do it just yet.
All app server's blasadmin settings are identical except for what makes them unique. Their hosts file are all the same, and have an entry for the VIP of the console server pointing to their own primary IP address (so each app server loops back only on itself when accessing the app service and NSH proxy service urls which also point to the VIP).
All app servers are set to bind their socket to their primary IP address only, and all can be managed via the infra management (edit works, which means the RMI and multi-app server communication works too or I wouldn't be able to manage that one).
I just want to know what exactly is done in the back-end to generate whatever address is shown in there, where does it get it from precisely?
Just to add another observation here...
As far as I know, it's always done this. In fact, we run with 3 node BSA configuration (all on RHEL) with a CONF instance running on each node. I can tell which CONF instance I am connected to (we connect via F5 VIP to the BSA farm) by looking at which of the 3 CONF instances displays the FQDN.
BSA has always behaved this way in our configuration, and I always wondered WHY myself?
And I know to use this behavior to verify which CONF instance my client is connected to!
the config/all that you connect to will resolve the other appservers - not sure why it would show the apipa ip though.
Bill, is there any way you can have someone check the underlying code to confirm exactly what it's doing to get the value between the parenthesis? Maybe it's a defect?
the config server you connect to has the remote server resolve itself and return the ip. is there a reason the 4th appserver would return the apipa ip ?
Not that I know of, and it's not always the same that returns that IP... so it's not consistent. All servers are configured the same network-wise... Same DNS, gateway, subnetmask, interface setup and vlan..., Same version of Windows, same hosts file config, all have a proper DNS entry, etc...