Symetrik Domino Consulting

I feel like talking like a cave man because the concept is like starting fire when people start to understand the benefits.

For a long time, I’ve been a pundit of “DON’T USE STATIC IP CONNECTION DOCUMENTS!” Not everyone will listen, maybe because I sound like a radical cavalier consultant admin who knows everything – offering up such new fangled ideas to an organization who does not have a global active directory container or single company-wide DNS suffix.

Here’s why STATIC is so bad:

We have a situation in a large office where which will be changing it’s IP address range to fit into the global IP address scheme standards. This means that all of the servers have to have their IP address changed. Excellent!…finally following up with some standards.

The question came up on how this will affect Lotus Notes clients. The first thing I suggested was to go to a few of the clients to see how they are configured because nobody has a clue. I’m guessing that they all have static connection documents, which are not a 100% bad thing as long as the IP address field of the connection document has a resolvable name for the server. For example:the IP address field should be Notesserver which could be resolvable either via WINS, or by DNS if the server’s host name has a DNS entry and there is an alias (C-Name record) for just the hostname.

This is another great example of why Domino server application name should always be the same name as the computer host name. It makes life so much easier, and it’s so simple to do. It’s not skin off of anyone’s back. If your Windows 2003 server name is dominoserver, and your Domino server name is Dominoserver, and you run WINS, then dominoserver will automatically be added to WINS without any further interaction.

If your hostname is the same as the Domino name, you run WINS, and all of the Windows/Notes Client machines are in the same active directory (thus utilizing the same WINS infrastructure) then you don’t even need a connection document.

If you want to be “sure” then create a connection document to dominoserver with the name “dominoserver” in the IP address field.

If you use DNS instead of WINS, the principle is the same. Create your DNS entry for your server dominoserver.domain.com. If you can, create an alias for that DNS entry as just the hostname, which is dominoserver. This means that you’ll resolve both of these on a windows client that has the DNS servers for your organization defined (the windows clients can receive DNS server IP addresses automatically from DHCP).

c:\>nslookup dominoserver.domain.com
Server: dns1.domain.com
Address: 10.0.0.10

Name: dominoserver.domain.com
Address: 10.0.1.200

c:\>nslookup dominoserver
Server: dns1.domain.com
Address: 10.0.0.10

Name: dominoserver
Address: 10.0.1.200

This means that both names can be resolved without problem. This also means that you do not need a connection document. If you want to be “sure” – you can create a connection document for dominoserver and in the IP address field, put dominoserver.domain.com.

Some organizations will rely on the “Append primary and connection specific DNS suffixes” or “Append parent suffixes of the primary DNS suffix” or “Append these DNS suffixes” settings in the TCP/IP settings on all the clients machines. You will see this in organizations that may not use WINS, or have DNS setup in such a way that they cannot create an alias for the dominoserver.domain.com. The latter is usually the case in organizations that have multiple DNS suffixes under one root and are unable to create host name aliases for anything under the subdomains.

What happens is that there will be a DNS entry for dominoserver.domain.com, but no alias for dominoserver. So typing nslookup dominoserver produces no results. However, on client machines that have the “append…..” setting, the client will automatically append, the .domain.com onto the NSLOOKUP request, which then in turn finds the DNS entry.

This can create problems on servers or clients that do not have the “Append….” settting defined or turned on.

With all of the above said, you can see how much of a benefit it can be to have all of your clients configured with no connection documents, or with connection documents that have a resolvable name in the IP address field.

If your server’s IP changes, because of some outside force that requires that it must be changed, you can rely on WINS or DNS resolution on each of the client machines and you do not have to worry about any client downtime.

If you have configured each of the Notes clients with connection documents and those connection documents point to an IP address, then you must change each and every connection document. If the office is 20 staff, it’s not a big problem. What if it’s 400? That’s alot of work, alot of unnecessary work.

Another very helpful thing is to put the IP address of the server in the Net Address Field of the Notes Network Ports tab in the server document.

The benefit here is that when one server tries to connect to another server, this field is used. For example, when server A does not have a connection document to Server B, but they are in the same Notes Named Network (NNN), mail will route from Server A to Server B and vice versa. This is because if Server A cannot resolve the Server B’s name (or perhaps the Domino name is not the same as the hostname), Server A will know the IP address of Server B based on this field and be able to connect to it.

This is also used when servers are in a cluster. When a client connects to his home server, a cluster cache is stored in the clients machine. This cluster cache stores the IP addresses of the servers in that cluster. IF the IP address is stored in the Net Address field instead of a name, then the client will know and connect to the second cluster machine on the IP address. If a name is stored, then the name must be resolvable by the client machine or the client machine cannot connect to the second cluster server in the event that the first cluster machine goes down.