FQDN v IP for install & site pairing

[John_Balsillie]

During SRM installation, the local VC is specified. Either FQDN or IP adx can be used but FQDN is best practice. When pairing sites, the remote VC is specified and again, FQDN or IP with FQDN being best practice. But importantly, whatever method is used at install, then same method must be used when pairing.

My question is what if you don't? That is, what happens if you use opposite methods (FQDN then IP or vice versa) when installing then pairing? What breaks?

[John_Balsillie]

I was hoping that somebody might know the answer to this one but it's not looking that way.

When told that you "must" do something, I really think that we should be told why.

To add to this, I have tested using FQDN for the VC when installing SRM and the IP when pairing, intentionally against what we are told you "must" do in order to try determine what breaks if you use opposite naming methods. Nothing broke. All configuration steps worked and a recovery plan test executed successfully.

So again, why must the same method of naming the VC servers be used when pairing sites as used when installing SRM?

[timboddy · Accepted solution]

The documentation is strict in the interest of simplicitly. Basically, the need for the match has to do with SSL, and checking of server certificates. By default, when SRM connects to the VC server it expects the DNS assertion made in the alternative subject name of VC's certificate to be an exact match of the IP/FQDN used to reach that VC. If the local SRM uses the IP addr to reach a given VC and the remote SRM uses the FQDN to reach that same VC, for example, the assertion in the certificate cannot possibly match both values.

An exception to this is the case where during installation the user chooses to accept VC's certificate based on the thumbprint. In such a case VC's certificate gets checked on each SSL connection solely based on the thumbprint and the DNS assertion is not required to match. I assume that is the case you are seeing here.