OCS 2007 and 2007 R2 are just like many of Microsoft’s newer communications products in that they are heavily reliant on DNS being properly configured. Of course, DNS is a major player in all things networking today, but with OCS, we really don’t have the option of using TCP/IP addresses, we need to use names because names are used in certificates that are used everyone in OCS as well.
So, what DNS records do we need in a typical OCS deployment?
- Each OCS server needs a HOST (A) record.
- The Front End Pool needs a HOST (A) record.
- The Hardware Load Balancer needs a HOST (A) record.
- Then, we also need SRV records for automatic configuration of our client computers.
To create our HOST (A) records, we go to our DNS Manager in our administrative tools. We find our forward lookup zone, and then add a New Host (A or AAAA) record as below.
To create an SRV record, we will use the DNS Manager in our administrative tools. We find our forward lookup zone, and then add Other New Records then select the Service Location (SRV) option.
The above record would be used by an internal MOC client to find the OCS Front End server named OCSFE1 and it would then use a certificate and connect to the OCS environment by using secure SIP. We use similar SRV records for other purposes in OCS, too. If we have a Enterprise Pool, then we would create a HOST (A) record for the pool name, and then we would use the pool’s HOST (A) record for the Host offering this service field in the creation of the SRV record.
When it comes to the SRV records, we need them for:
- The Pool (or single server, if there isn’t a pool), so our clients can find the pool and connect to the OCS environment.
- The Edge environment, so our external clients can automatically find and connect to the Edge.
- Federation, so we can configure open federation with other organizations and their OCS environments.
Most organizations use the automatic configuration option to connect their Microsoft Office Communicator (MOC) clients to the OCS environment. The MOC clients then use the SRV records to find the point of connection. Their are four main SRV records that are used by the MOC client.
- _sipinternaltls._tcp.InfrastructureHelp.com – This record is used by internal users that will be using TLS to secure SIP.
- _sipinternal._tcp.InfrastructureHelp.com – This record is used by internal users that will not be using TLS.
- _sip._tls.InfrastructureHelp.com – This record is used by external users to find the Edge server and it uses TLS.
- _sip._tcp.InfrastructureHelp.com – This record is used by external users to find the Edge server and it does not use TLS.
The above SRV records are processed in the order listed. If one of the records can be resolved, then it will attempt to use it to connect. The MOC client will not try to use another record if it is able to resolve any of the ones above it. After the SRV record is found and resolved, the MOC client will then query for the associated HOST (A) record. If there are any failures after find an SRV record, the MOC client will fail in its connection attempt. It will not try any of the other records.
So, the logon process goes like this:
- DNS lookup for SRV record using the SIP URI of the client’s user information. See above on the order for the search of the SRV records.
- Resolves to the Host name of the record that provides the service in the SRV record.
- Resolves the Host name to the IP Address
- Tries to connect to the IP address, which could be a hardware load balancer virtual IP, the address of a director, the address of a pool, or the address of a single front end server.
The last step is where we need to understand what the IP address should be in our SRV record. The flow chart below helps explain which IP address should be used in the SRV record.
We also need an SRV record for Federation, which will look like _sipfederationtls._tcp.domainname.com, if we want to support DNS discovery by federation partners.
Without the proper DNS records, we can’t connect to our OCS environment. We need the names to be correct because names are used in our certificates, and we need the TCP/IP addresses to resolve properly, or we will never get to the right server(s).