I've got a second Primary Server that is listing it's "Server Address" as 127.0.0.1 and is giving me certificate headaches. What's particularly strange is that when I look in the zmd-messages.log on either the server agent or an affected device, I do see a certificate successfully import using the DNS name but then a failed line for the IP address of the server, so like this (IPs changed out, but they're correct in the log):

[DEBUG] [10/21/2010 07:46:04.359] [1656] [ZenworksWindowsService] [22] [] [CertManager.AddCertificates] [] [Adding cert: 2ef246fabb9fc917f272d97a1ec9586c for hosts: mars.somewhere.net, 1.2.3.4] [] []
[DEBUG] [10/21/2010 07:46:04.359] [1656] [ZenworksWindowsService] [22] [] [CertManager.AddCertificates] [] [Adding cert: 9b97572f6c5da0b7e31bd4573ff9d8af for hosts: earth.somewhere.net, 5.6.7.8] [] []
[DEBUG] [10/21/2010 10:29:17.640] [1656] [ZenworksWindowsService] [24] [] [CertManager] [] [No matching certificate found for host: 1.2.3.4] [] []

The first server referenced, Mars, is the second primary. The second server, Earth, is my working primary and the one that holds the CA. A line like the error for Mars never shows up for Earth nor does a successfully imported line for it, so I'm guessing Mars shouldn't be trying to do that either?

Anyone have any idea how I can get Mars to see itself as it's real IP Address rather than 127.0.0.1 and deal with whatever inveitable certificate error that's going to cause?

Further info. The working server's initial-web-service only lists the DNS name of the server at the top (so http://earth.somewhere.net]) while the non-working one shows http://mars.somewhere.net;https://localhost:443;https://127.0.0.1:443 (and then what look to be a couple "bad" characters, like little boxes before the actual cert).