It's not really a DNS issue. Well, it is and it isn't.
Communication between the Avamar Administrator GUI and the Avamar Administrator Server currently relies on an older technology called Remote Method Invocation (RMI). There is a field in mcserver.xml called rmi_address. This rmi_address is sent back to the GUI and used to initialize the connection between the GUI and the Server and if the field is blank, it sends back the primary IP address of the utility node (typically bond0). To resolve this issue, the rmi_address field should be set to the short name of the Avamar server (utility node or single node).
Once the rmi_address has been updated, any systems where the GUI is running need to be able to resolve that short name to the IP address where the server can be reached in that environment. Typically this means having the local DNS updated so it correctly resolves the NAT IP of the utility node.
RMI will be going away in an upcoming release and this will no longer be an issue.
There are a few members of the engineering team kicking around on the forums. We pride ourselves on comprehensive, logical and quick
With server-side activation, the issue is likely a different one. The client agent listens on port 28002 and in order to activate a client from the server, the Administrator Server (also called the MCS) must be able to reach the client on that port.
If this is 1:1 NAT (where the clients can be reached through the NAT), you should be able to get them to activate by manually setting their paging address so the server knows how to reach the agent on port 28002. If the clients aren't routable through the NAT, they will have to be activated from the client side.
You should not modify the lib version of mcserver.xml -- it's the gold copy. This RMI issue does not involve the GSAN at all so there's no need to restart it.
One more thing to check -- is lm running on the utility node? That's lm as in login manager. If it's not running, that would explain the issue. You can check if it's running using ps -ef | grep lm. If you find that it's not running, run the following command as the root user to start it:
service lm start
If you find that lm is running, I would recommend opening a service request so support can take a look at the system directly.