I've got a second Primary Server that is listing it's "Server Address" as 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,] [] []
[DEBUG] [10/21/2010 07:46:04.359] [1656] [ZenworksWindowsService] [22] [] [CertManager.AddCertificates] [] [Adding cert: 9b97572f6c5da0b7e31bd4573ff9d8af for hosts: earth.somewhere.net,] [] []
[DEBUG] [10/21/2010 10:29:17.640] [1656] [ZenworksWindowsService] [24] [] [CertManager] [] [No matching certificate found for host:] [] []

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 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; (and then what look to be a couple "bad" characters, like little boxes before the actual cert).