Considerations for changing a server IP address
Changing the IP address of an IBM® Domino® server can cause access issues.
Before changing a server's IP address, consider the following possible problems, and resolutions:
- Problem 1: If the server's previous IP address is stored in any
server connection documents or server documents, when that server's
IP address is changed in DNS and on the server itself, these old connection
or server documents causes connection failure.
Solution: Use the DNS fully-qualified domain name, not the IP address, as the network address stored in the server connection documents and server documents. You can then change the server's IP address in DNS without having to change the server connection documents or server documents. Changing the network address from the IP address to the DNS name can be done at any time.
To modify the server connection document, open the server connection document. On the Basics tab, if Local Area Network is selected in the Connection Type field, click the Advanced tab and check the entry in the Destination server address field. If the field contains the server's IP address, delete the IP address and enter the fully-qualified domain name. The server-based Domino® Directory and the client-based contacts can have this problem.
To modify the server document, click the Ports tab for the Net Address for TCP ports. If the field contains the IP address, change the entry to the proper fully-qualified domain name.
- Problem 2: IBM® Notes® clients
and Domino® servers cache
the IP address that was used to successfully connect to a server.
If this cache entry exists, when the server's IP address is changed,
the old cached address may cause connection failure.
The following solutions can resolve this problem. Solutions are listed in the order in which they should be used.
Solution 1: A fast connection algorithm is used if the client or server had successfully connected to the same server earlier in the day. If a successful connection has not yet occurred today, a slower algorithm is used and the cache is bypassed. To avoid this problem, change a server's IP address late in the evening, but before midnight.
Solution 2: The cache is rewritten following successful connection to the server. The cached address is the address entered by the user, not the resolved IP address. If users connect to servera/renovations by entering servera.renovations.com, the cached address will be servera.renovations.com, not 1.2.3.4 and the problem will not occur.
Solution 3: If a user tries to connect to the server by its Notes® name, for example, servera/renovations, the stale cache entry is used. If the user tries to connect using the server's fully-qualified domain name, for example, servera.renovations.com, then the cache will not be used, the new address will be fetched from DNS and the correct new address entered in the cache. To make this successful connection using the fully-qualified domain name of the server, use or .
Solution 4: The cache is stored in the following Notes® fields in the location documents for the client and in the server document for the server:
$Saved Addresses$SavedDate$SavedPorts$Savedservers$SavedTriedDate
If these fields are deleted from the location or server document, the old IP addresses in the cache cannot be used. This method can be confusing because the Notes® items are rewritten when the client or server exists from an in-memory copy. Therefore, to use this method to clear the cache for the client, create the agent in the local address book and then switch to the another location document and exit the client. Restart the client, and then run the agent to clear the cache for all other locations. Switch to your normal location.
Sample agent formula language code to clear the cache:
FIELD $SavedAddresses:=@DeleteField;FIELD $SavedDate:=@DeleteField;FIELD $SavedPorts:=@DeleteField;FIELD $SavedTriedDate:=@DeleteField;FIELD $Savedservers:=@DeleteField;SELECT @All
Solution 5: Disable the use of the cached addresses by using the NOTES.INI setting
DONT_USE_REMEMBERED_ADDRESSES=1If the client uses multiple or slow port technologies, this technique is not encouraged because it can cause a long delay in reporting that a server is down.