[Editor's note: The Special Report column is brought to you by Lotus Support, and features articles that dive into issues important to both Domino/Notes administrators and developers.]
Have you ever tried to combine two Domino servers into one server? How about rename a Domino server? Both of these situations sound simple -- register and install a new server, and then move all of the resources from the old server(s) to the new one. In theory, that is true. The reality, however, is a situation far from simple. Changing server names, for whatever reason, is a tedious task that tests your attention to detail.
Fortunately, Domino R5 introduces a new feature that aims at reducing the tedium of server combines and name changes, and even works with pre-R5 servers. The Decommission Server Analysis tool is a new feature that performs a comparative analysis between a server slated for the junkyard and its successor. The result is a detailed report identifying databases and documents that require special attention prior to taking the server out of its production role. This new feature isn't designed to do the decommission work for you, rather it's designed to help you avoid a loss of service when a server is removed. It also provides an excellent foundation for a decommission "to do" checklist. An overview of this feature, and why you might need it, is the focus of this Special Report.
Putting the challenge into context
To completely appreciate the Decommission Server Analysis tool, you have to understand why anyone might want to decommission a server in the first place.
Back in the days of R3, Notes servers couldn't support as many concurrent connections as they do today. When R4 was introduced, administrators discovered that a single server, properly configured, could do the work of several R3 servers. In an effort to ease server administration, many administrators began combining several servers into one, high-powered machine. Server combines usually involve "decommissioning" one or more production servers, and relocating the databases to the new server.
Aside from combining servers, administrators occasionally want to rename a server (the original naming scheme may have worked initially, but failed to convey the purpose of each server). Changing a server name is similar to combining a server except instead of several machines merging into one, a single server moves from one machine to another. Once again, changing a server name is essentially the process of "decommissioning" one server and replacing it with another.
Whether you're combining two servers into one server, or renaming a server, the result is the same -- the old server name disappears and a new server name takes its place. The impact of such a change is hard to imagine unless you've gone through it. You've got to:
- Check each database for formulas that contain specific server name references
- Update Domino Directory documents, such as Connection and Program documents, to reflect the new name
- Make sure that if the old server issued cross certificates, the new one does the same
- Notify foreign domains that access this server about the change
- Inform users about the new location for databases, including their mail database, if necessary
- Make sure the network protocols on the old and new servers match
- Make sure the new server runs the same server tasks as the old machine
- Replicate all the databases from the old server to the new one
- Update mail routing tables to ensure that mail gets delivered correctly
Even from this short list, it's easy to see why server combines and name changes are such a serious task. The steps themselves aren't difficult; however, it's the possibility of forgetting something that makes server combines and name changes difficult, and that's where the Decommission Server Analysis tool comes in.
What the tool does
The Decommission Sever Analysis tool runs from the new Domino Administrator. When you start the tool, you specify a source server (the server you're putting out of service) and a target server (the server that's taking the place of the old one). Once the source and target are specified, you can run the analysis. A comparison of the source and target servers takes place and the findings are recorded in a results database -- Decommission Server Analysis (DECOMSRV.NSF). This database contains detailed information identifying any inconsistencies between the source and target server that require attention before taking the source server out of production.
The results database becomes the foundation for your decommission "to do" checklist. There is a separate document in the database for each item that is compared during the analysis. These items may or may not need your attention; however, any item that requires attention appears in the view with an eyeglasses icon next to it. Once you've dealt with each item that requires attention, you can run the analysis tool again and double-check if you made the appropriate changes.
Taking a quick spin
To get a better idea of what this tool does, try it out in your environment. You can use a couple of test servers or production servers. The analysis tool doesn't do anything other than a comparison. Therefore, you're not obligated to follow through with the decommission process after running the tool.
- From the Domino Administrator, click the Servers/Analysis tab.
- From the Analysis tools, click Decommission Server Analysis:
- Select the source server and the target server from the Decommission Server Analysis box (both servers must be in same domain).
- Click Results Database.
- Enter the name of the server where the results database should be created. The default is Local.
- Enter the title and the file name for the results database (the default is decomsrv.nsf), and click OK .
- Select to either append data to this database (the default), or to overwrite this database.
- Click OK.
Once the analysis is complete, the results database opens to the Reports view displaying a categorized list of the items analyzed. Each item is represented by a document. If a problem or inconsistency is detected between the source and target server during the analysis, an eyeglasses icon appears next to the document in the view. The following screen shows the Reports view:
Notice that the "Databases - Mail Users" document has an eyeglasses icon next to it. Open this document and you see a list of users that use the source server as their mail server. Here is one action item for your checklist -- you need to move these users to a new mail server. The following screen shows the "Databases - Mail Users" document, which lists the users that have the source server as their mail (home) server:
As you can see in the "Databases - Mail Users" document, there are six informational fields. Most of these are self-explanatory; however, here's a quick description of each field:
- Report category: The section or category that the document belongs to.
- Report title: The specific field or item analyzed.
- Report data: The date of the report generated.
- Server to be decommissioned: The source server (the one you're removing).
- Server to accept responsibility: The target server (the new server taking over).
- Report details: Additional information that helps you determine what you need to do.
Even though the "Databases - Mail Users" document provides one action item for your "to-do" checklist, don't act upon this item until you've reviewed each report document. The server decommission process is a very serious action. You must proceed with caution, and only after a complete and methodical analysis. For example, consider the report document shown below, the "Databases - No Matching Replica" document. This report lists all the databases on the source server that need a replica on the target server:
The natural response to this report document is to create a matching replica for each database on the target server. If you proceed with this response, you might run into a problem with conflicting file names. To avoid such a situation, open the "Databases - Name Conflict" document, and look for conflicting file names:
So, the "Databases - No Matching Replica" and "Databases - Name Conflict" documents work in tandem. Before you create a new replica on the target server, you can see which databases may need a new file name -- to avoid a name conflict.
Each comparison the tool makes is fairly individual. Relationships between analysis items isn't part of what this tool does. Therefore, you need to review each report document and make your own comparisons before taking any action. Aside from the report document comparison, you'll still have to do additional analysis yourself. For example, does the source server have databases with formulas that reference a specific server name? The analysis tool doesn't search each formula in each database and create a flagged document in the analysis report. You still have to do that analysis yourself.
Of course, just because a document appears in the Reports view with an eyeglasses icon next to it doesn't mean you have to resolve that conflict. There are situations where you don't want the target server to exactly match the source server. For example, if the source server has SPX enabled as one of its network protocols, you don't have to enable it on the target server. Perhaps your network environment has moved to TCP/IP and no longer uses SPX. The server decommission process is the perfect time to turn off that protocol.
But wait -- there's more
The role of the analysis tool is to help you avoid a loss of service for your Domino server, and to help build a foundation for a decommission "to do" checklist. The tool gives you a head start by giving you an idea of the areas that you should examine before beginning the decommission process.
Future incremental releases of Domino R5 may bring additional functionality to the Decommission Server Analysis tool. One such feature taps into the power of the Administration Process, which will help you take action on some of the report items such as creating new replicas. Even without this feature enhancement, however, the Decommission Server Analysis tool can still help you get started today with the challenge of decommissioning a server.