Previous Page TOC 

— 9 —

Designing Your Notes Network

Designing your Notes network involves making all the decisions necessary to configure your Notes servers and clients and to design and implement your pilot application. Of particular importance is the creation of a naming scheme for your users and servers that balances the competing requirements of administrative overhead, user convenience, and security. The other key goal is to design network topologies that are easy to administer while providing a scalable, extendable architecture.

This chapter covers the advantages and disadvantages of hierarchical naming. Naming schemes for your servers, users, domains, and networks are recommended. The chapter also discusses configuring mail routing and Notes network topologies. Before designing your Notes network, you should review Chapter 5, "Building a Deployment Plan." It's okay to install a few Notes clients and servers for use by the project team before you begin to design your production network. Just make sure that everyone realizes that the network built for the project team isn't the production network. You shouldn't design your production network before you have taken an assessment of your enterprise and defined the scope for your Notes deployment. These are critical factors in deciding the naming schemes and network topologies that will best suit your organization.

In Chapter 5, "Building a Deployment Plan," sixteen steps common to designing any Notes network are listed. Of those sixteen, several have already been covered in Chapter 7, "Determining Hardware and Software Needs." In this chapter, I cover the remaining steps. These are the steps to designing a Notes network:

  1. Identify supported desktop platforms.
  2. Identify supported server platforms.
  3. Identify supported network protocols.
  4. Develop a WAN strategy for remote access.
  5. Decide the location of servers.
  6. Identify your replication architecture (network topology).
  7. Size the hardware for desktop and servers.
  8. Identify current IS systems that must integrate with Notes.
  9. Identify current desktop applications that must integrate with Notes.
  10. Decide which application-development tools to support.
  11. Create naming guidelines for people, servers, and groups.
  12. Name your Notes domains.
  13. Name your Notes networks.
  14. Name your Notes servers.
  15. Choose gateways for mail, fax, Internet, etc.
  16. Assign users to home servers.
In Chapter 7, "Determining Hardware and Software Needs," I covered steps 1, 2, 3, and 6. The rest of this chapter is organized around the remaining steps in designing your Notes network. When you complete the design of your network, you should have decided everything you need to begin installing Notes servers and clients. Before releasing a pilot application, you should also complete the development of your standard operating procedures as outined in Chapter 5, "Building a Deployment Plan."

Throughout this chapter, exit criteria appear for each step. Remember that, as discussed in Chapter 5, "Building a Deployment Plan," and Chapter 6, "Customizing Your Deployment Plan," the goal isn't to try to plan out your entire installation before taking any action. You repeat (or at least review) every step in this chapter after the pilot, so don’t be afraid to make a decision and move ahead. For example, you may severely limit the desktop platforms you support during the pilot, but then decide to support more platforms after the pilot. The only exception to this plan is your naming guidelines. Due to the administrative effort required to change names, you should try to draw up guidelines that can survive as long as Notes survives (because they will survive, whether or not you want them to do so).

Step 1: Identify Supported Desktop Platforms

This step is covered in Chapter 7, "Determing Hardware and Software Needs." In summary, your main considerations when choosing a desktop platform are This step is complete when you can specify every client platform that you will need to support over the next year of your Notes deployment.

Step 2: Identify Supported Server Platforms

This step is also covered in Chapter 7. In summary, these are the key points to remember: This step is complete when you can specify every server platform that you will need to support over the next year of your Notes deployment.

Step 3: Identify Supported Network Protocols

This step is covered in Chapter 7. In summary, the key points to remember are (all together now): This step is complete when you can specify every network protocol that you will need to support over the next year of your Notes deployment.

Step 4: Develop a WAN Strategy for Remote Access

Those enterprises that have mobile users and remote offices need to develop guidelines for when remote users should have a locally-available replica of a database and when they should dial directly into your headquarters servers. Your primary considerations are cost and performance. Economics is the primary determinant, although other advantages favor replication of data to a remote server over online access. You should evaluate these types of connections: The last three options require data to be replicated to a remote server to provide local access to infrequently connected servers and/or workstations, and can't be used in every instance.

You need to perform this analysis for each remote site you plan to support. For each site, ask the following questions:

You can mix and match local access to a replica and dialing into headquarters. Use local replica copies for commonly used databases and direct dialing for infrequently used databases. Always bias your selections toward online access (except for dial-up users, who should favor local replicas). Online access minimizes support costs and is getting cheaper all the time. By the time you actually get a working application installed, the cost of supporting online access will be less than your estimate because telecommunication costs are constantly falling.

These are the advantages of having your users dial directly into your headquarters servers:

These are the advantages of placing a server in a remote office and replicating databases: The following list shows the disadvantages of having your users dial directly into headquarters: There are two ways to support online users: have them dial directly into the network with some network package, such as TCP/IP with a SLIP connection; or have them use Notes passthru. These options are available no matter what form of remote connection you choose (dial-up, Internet, private network). Network packages will allow remote users to access every server on the network, not just Notes servers. Notes passthru allows access only to Notes servers, but has some nice security features. For many people, configuring passthru will be easier and more natural than setting up a SLIP connection (or any functionally similar connection). SLIP connections can be a potential security leak on your network. Use remote network connections when your mobile users need to access non-Notes servers, or if you already support remote connections to your network. Use Notes passthru when only Notes resources are needed or security is a concern.

Before completing the design of a remote-access strategy, you should have a written set of guidelines for use by your administrators on when they should place a remote server and when they should have users connect through dial-up. The cost of online access versus replicating a database should be the primary determinant. Figure 9.1 shows the basic calculations used to compare the cost of placing a remote server and the cost of users dialing into a central server. You should perform these calculations for a variety of database sizes and connection costs and distribute the results to anyone responsible for placing remote servers.

Sites that already have a remote server usually prefer to create replicas of any new databases. Once you have placed a remote server, the cost of replicating an extra database is small. Each application still should be analyzed before automatically creating a new replica. If users need access to the latest data, if the database is infrequently used, or if the remote server is operating at capacity, don't create a new replica.

Figure 9.1.
Compare the costs of online access versus replicating databases when deciding to place a remote server.

Don't forget to update the grid often. Telecommunications costs are falling rapidly, making online access more attractive over time. Review the placement of remote servers every six months.

This step is complete when you can detail the communication costs associated with each remote site. You must be able to specify the type of connection and whether a remote server will be placed. You should have a general idea of the performance remote users can expect.

Step 5: Decide the Location of Servers

Once you have set up your guidelines for remote placement of servers, you are ready to decide the location of your servers. Place database servers and mail servers first, and then decide on dial-up servers. Hub servers will depend on the replication architecture you choose.

Servers at the headquarters location should be stored in a secure environment, not randomly placed around the various floors. Remote locations should consider using secure closets to house the Notes server. Decide the number of servers that you need, taking into account the specialized roles that each server should play. I recommend dedicating servers to mail, dial-up, and hubs. Most installations will start with a single hub server, if they have one at all.

This step is complete when each site has a list of the servers that will be installed at that site.

Step 6: Design Your Network Topology

Before deciding your Notes network topology, you should have an up-to-date diagram of your telecommunications network, including all current printers, servers, bridges, and routers. The diagram should clearly identify any remote servers. There are two basic topologies for a Notes network: the hub-and-spoke topology and the serial-connection topology. Figure 9.2 shows an example of each network topology. The connections between servers are determined by the Notes connection documents in the Notes Name and Address Book.

Figure 9.2.
The two basic Notes network topologies.

Hub-and-Spoke Topology

I recommend that anyone with more than five servers use a hub-and-spoke network topology with specialized servers for mail, hubs, and backup. The Notes hub server is completely dedicated to replicating data between the various spokes. The spoke servers don't connect directly to each other, so for a change on Spoke A to get replicated to Spoke B, it first has to replicate through the hub. The hub initiates all replications in a "round robin" manner, going around the spokes. The number of spokes that you can connect to a particular hub is completely dependent on the types of applications that you roll out, the frequency of your replications, the amount of data transferred, and the hardware configurations you are using. Typically, 5 to 20 servers can replicate with a single hub. If you need multiple hubs, consider forming a tree configuration with your production database servers forming the leaves of the tree. Figure 9.3 shows a tree configuration.

Figure 9.3.
A tree topology allows multiple hubs to communicate in an orderly manner.

The hub machine can also serve as a natural link between multiple networks. Having a gateway hub saves money by eliminating the need to install dual-protocol stacks or multiple network cards in all your spoke machines. The hub machine is also a natural server to function as a bridge between various Notes domains.

There are several advantages to using a hub-and-spoke topology:



NOTEEven when using a hub-and-spoke network topology, you can set up a few direct connections between servers for replicating high-priority data or for replicating large amounts of data between two servers. Be careful. You should have clear guidelines on when you will or won't set up a direct connection between two servers. Specify in the connection document the exact databases that these two servers should replicate. Otherwise, if you set up a direct connection between two servers to service a single application, those two servers will replicate all databases that they have in common. Default replication is between servers, not between databases.

See Chapter 10, "Installing and Configuring Notes Servers," for details on setting up a hub-and-spoke architecture.

Ring Topology

For smaller organizations with only a few Notes servers, the cost of an additional hub server isn't justified. In this case, you should set up connection documents so that all servers contact all other servers. Figure 9.4 shows a diagram of this topology.

Figure 9.4.
When you have fewer than five Notes servers, set them up in a ring.

Note that the number of connection documents grows quickly as the number of servers increases. Plan ahead. If there is any possibility that you will install more than five servers over the first year or two, begin planning immediately for a hub-and-spoke topology. Designate spokes and let one server function as a hub. During the initial phases, it makes sense for small organizations to have all servers connect directly to each other.

See Chapter 10, "Installing and Configuring Notes Servers," for details on setting up a ring network.

In addition to deciding the replication architecture for your Notes network, you should dedicate servers to particular roles. The following servers should be set up:

Enterprises that require 24 hours per day/7 days per week operation need to set up a backup server. The backup server connects to your hub server.

Mail servers, backup servers, and external servers connect directly to your hub just like any other spoke server.

This step is complete when you can draw a network diagram that shows the logical connections between Notes servers. All servers planned for the first year should be shown.

Step 7: Size the Hardware for Desktop and Servers

When you know the geographic location of each database server, you can estimate the hardware configurations needed for each site. This step is covered in Chapter 7, "Determining Hardware and Software Needs." In summary, the key points to consider are these: This step is complete when you have a minimum supported configuration for each client and server platform in your organization. Specialized configurations for backup servers, dial-up servers, and hub servers should be slight variations on a central theme. You should be able to generate purchase orders for hardware at this point.

Step 8: Identify Current IS Systems That Must Integrate with Notes

The planning that you have done before attempting to design your Notes network is useful here. In your assessment of the enterprise, you held joint design sessions with key stakeholders throughout the enterprise. You have identified the types of applications that you are likely to develop for each of your business units, and you have identified the information feeds available for each of these applications. Now is the time to decide how you will actually get that data into Notes. If the data is already stored in a current IS system, you need to decide whether you can rely on a third-party product to provide the link, or whether you need custom development.

Notes system integration is perhaps one of the most challenging parts of a Notes rollout, often requiring custom application development using the Notes C API. Before diving into custom programming, closely investigate the products available. More and more third-party products are capable of connecting Notes servers to an ever-increasing range of legacy IS systems, eliminating the need to develop your own (expen$ive) bridges.

The first step in deciding whether to buy or build connections to your back-end systems is identifying which ones have to integrate directly with Notes. For example, you may have an order-entry system already implemented and working fine. You may want to feed orders into Notes and then use Notes' workflow capabilities to process those orders, routing them through your internal departments. If your order-entry system is built on a mainframe system using an old hierarchical database, you need to develop custom code that pulls data on a regular basis and feeds it into a Notes database.

When you have identified the IS systems that must be integrated with Notes, enter them onto your Notes network diagram. Your diagram should indicate which servers will connect to your other systems.

This step is complete when you have an updated diagram of your Notes network, showing all systems that will provide data or get data from Notes (at least for the pilot application).

Step 9: Identify Current Desktop Applications That Must Integrate with Notes

You probably have already rolled out some desktop applications for your users. In some applications, it makes sense to integrate the data into Notes. You need to identify the applications people are currently using (which you should have accomplished when you assessed the enterprise) and decide which ones need to integrate with Notes. The desktop integration issues are different for each of the supported platforms—Mac, Windows, OS/2, and UNIX. Your application developers will have to decide the best way to link Notes and personal-productivity applications. Linking them is really an application-development issue. Check with any of the books on Notes application development.

This step is complete when you have a list of the applications that must integrate with Notes (at least for the pilot). You don't need to decide exactly how each application will be integrated. This is accomplished in the next step.

Step 10: Decide Which Application-Development Tools to Support

When you have a list of systems that will connect to Notes, and a general idea (from the enterprise assessment) of the types of applications you need to develop, you are ready to decide which application-development tools to support. Remember, fewer tools is better and one tool is best. If you can build your applications using only the Notes interface, Irecommend doing so.

The Notes interface, while more powerful in Release 4 than in previous versions, is still limited. To have complete freedom at the user-interface level, you will have to move to a tool such as Visual Basic or PowerBuilder. There are specialized products that link Visual Basic, PowerBuilder, and others to Notes. In fact, virtually every application-development tool is building a package that allows it to work with Notes databases. Carefully evaluate the power of these links. Some of them may not allow direct access to all Notes features, including access to views, navigators, and the creation of agents. Be sure to run a few quick tests with all tools to quickly exercise their abilities before making a final decision.

This step is complete when you have a complete list of the application-development tools that will be used to build Notes applications. You should specify a tool or product for each type of application you will build and for each system or product that must integrate with Notes. This list will be used to develop a training shedule for developers and administrators.

Step 11: Develop Naming Guidelines for Users, Servers, and Groups

Naming is one of the most important and least understood parts of Notes. The names you choose will affect the amount of effort needed to support your Notes network. When developing naming guidleines for your users and servers you need to You have two fundamental ways to name servers and users: flat names and hierarchical names. Flat names are simple names—for example, John Doe or Mary Smith. Hierarchical names are a combination of a person's name along with some other distinguishing characteristic, such as the name of the company he works for and perhaps the name of the organizational unit that he works in. Hierarchical names are designed to solve the problem of uniquely identifying people on large networks. The use of flat names often leads to mail IDs such as ADAHL3. If you want to send mail to Andrew Dahl, should you send it to ADAHL, ADAHL2, or ADAHL3? It's not clear. The hierarchical names for these three people make this clear: I recommend hierarchical names for all organizations, large and small. The world is moving to hierarchical names; if you ever expect to tap into a network beyond your own company limits, you should be using heirachical names.

Let's take a look at how hierarchial names—also known as distinguished names—are put together. A hierarchial name in Notes is modeled after the X.500 specification. A distinguished name is a combination of a common name, an organizational unit, the organization, and an optional country name.

You combine these units in each component of a distinguished name with slashes. Example of valid distinguished names:

Advantages of Hierarchical Names

Hierarchical naming is quickly becoming the preferred method of naming users and servers. Hierarchical naming takes some planning, but offers several benefits:  

Figure 9.5.
External servers can access servers certified by descendants of the external server's cross certificate.

Disadvantages of Hierarchical Names

I recommend that all Notes installations use hierarchical naming. Whether yours is a large organization or a very small organization, the advantages outweigh the disadvantages. In the spirit of full disclosure, however, I hereby list the disadvantages that are associated with using hierarchical names: I hope you're not surprised that the list of disadvantages is shorter than the list of advantages. For a complete discussion of certificates and how they are used to create distinguished names, you see Chapter 3, "Understanding Security."

Creating Organizational Unit Certificates

One issue common to naming both people and servers is whether your organizational unit certificates' names should be based on departments or on geographic locations. Creating organizational unit certificates based on departments will more easily provide a tight level of security to your data through the use of wild cards (assuming that access to your data will be based on departments more often than geography). I recommend the use of departmental naming schemes. In large organizations, you may need to use more than one level of organizational unit certificate (for example, John Doe/Legal/Marketing/Acme). If your organization is highly decentralized, with each geographic entity acting as an independent business, use a combination of departments and geographic names (for example, John Doe/Legal/Columbus/Acme).

Departmental naming schemes can result in increased administrative burden due to reorganizations and transfers. When your corporation reorganizes, whole departments go away and the people in them are assigned to other departments. To maintain a consistent naming scheme, you will have to recertify all users affected, as well as update any access control list or group in which they appeared. Transfers between departments result in a steady stream of recertifications when names are based on departments. When Bertie (Bertie/Fittings/Acme) transfers to Accounting, her name must be changed to Bertie/Accounting/Acme. Whenever a person's user ID changes, the user ID must be recertified.

The use of geographic names minimizes this problem because it is less common, although still possible, that people transfer between geographic locations or that geographic locations disappear. When names are based on geographic locations, you don't have to change a person's user ID when he transfers between departments but stays at the same site.

Both departmental and geographic naming are equivalent in providing unique names within your organization. Department names and geographic names also are equivalent in their capacity to provide security, although departmental naming is likely to reduce the administrative burden of maintaining tight control through the use of wild cards. Geographically based organizational units can work better in providing decentralized management of your certificates allowing you to have a certifier at each of your major geographic locations. This avoids having to have a remote certifier certify users he's never met. Both departmental and geographic based certificates are equivalent in providing the ability to segregate users into groups so that you only need to recertify a small portion of your organization should a certificate become compromised. Departmental and geographic certificates that all inherit a common organizational unit are equivalent in allowing users to authenticate each other's identity.

Whether you go with departmental or geographic names, the actual names that you use should be cleared with the people who are going to have those names. Names are, in some corporate cultures, a particularly sensitive area.

Naming People

Keep in mind the purposes for which a person's name will be used. A person's name is used in mail routing and in access control lists. For both of these uses, the uniqueness of a person's name is the key requirement.

When addressing mail, people don't like to type long names. You may think that this would be a major disadvantage of hierarchical names (they can get quite long). This isn't the case. When addressing mail, just type the common name of your recipient. Notes will search the Name and Address Book for matches. When there are multiple matches, a list is presented. Simply choose the correct name from the list. The use of hierarchical names occasionally results in a few extra mouse clicks. These extra mouse clicks can be avoided for commonly used recipients by creating an entry in your Personal Name and Address Book. Use a memorable but unique alias for the recipient when creating the entry. When addressing mail, simply enter the alias. Notes will take care of the rest.

Of far more concern is Notes' ability to deliver mail. To deliver mail, Notes requires unique names within a domain. Hierarchical names are designed to provide unique names. Flat names result in strange abbreviations in an effort to provide uniqueness. Flat names can end up making mail addressing more difficult.

Even hierarchical names can be further clarified through the use of middle initials. Irecommend the use of middle initials. Even in small organizations you should plan ahead and use middle initials to help distinguish names from one another. The middle initial should only appear as part of a person's fully qualified name (Robert E. Lee/Columbus/Reps). The person's simple name shouldn't contain the middle initial (Robert Lee).This keeps mail addressing simple while making name conflicts even more unlikely.

Here I'm talking about the actual name entered in the Name and Address Book for each person. Whether to use aliases or not is a more difficult decision. You need to decide whether allowing aliases will create more confusion in your organization (with users wondering, "What is that person's name?" and "Who belongs to this name?") than it removes.

Another scenario to consider is when people are commonly known around the office by a nickname and people want to send mail to that nickname. If you require a person's Notes name to be their full legal name, you will have some confusion and cause your support staff to spend time explaining why mail isn't being delivered to this person. I have no recommendations on the use of aliases. In most organizations, they aren't a problem. If you allow aliases or nicknames, you need to decide whether that nickname will be that person's only name to Notes or whether that person should have multiple documents in the Name and Address Book, one with the real name and one with the nickname. If you allow nicknames, I recommend creating a second entry in the Name and Address Book for that person.

Avoid using names with underscores because Internet gateways will translate an underscore into a space. This will prevent your internal staff from sending or receiving mail from the Internet.

Naming Servers

Server names are visible to the user and should provide some clue as to the data stored on that particular server. Server naming is an easy-to-overlook aspect of designing your Notes network. It's an extremely important step in your Notes network design. Notes server names will be visible to users as part of the names of the databases on their desktops as well as in the list of servers from which they are allowed to choose. Server names are also difficult to change. They appear in many places, so it's important to choose names that can help guide your users to a proper selection when they are searching for a database. Choose server names that will retain their meaning as you shift servers around and as your Notes deployment grows. When naming your servers, take into account the following possible issues:

Naming Groups

Groups are simply lists of people and servers. Groups are used, as are people's names, for mail routing and access control. The primary benefit of using a group is that users save keystrokes when sending broadcast messages. For example, if you have twelve people in your Marketing department, you can create a group called Marketing and list all twelve people within it. To send a message to all twelve people, you simply need to type Marketing for the address and the message is sent to all twelve people.

Groups also simplify access control lists. Groups of servers are common in access control lists. Because access control lists are duplicated to many databases, the administrator saves significant time by using groups. For example, without the use of groups, when a new server is added to a domain, every database in that domain might have to have the new server's name added to the access control list. With groups, the new server is added once to the group of servers comprising the domain (this group is generally called LocalDomainServers).

Group names should be relatively short and easy to guess. Group names should also be fairly descriptive of the purpose of the group. There are two situations to consider: permanent groups within your organization and temporary teams. You may create groups for particular projects, or you may create group names based on geographic or departmental boundaries within an organization. You don't need to choose a single way of naming groups. You can easily create and delete groups as you need them. Some group names are created to ease the administrative burden, such as the default groups listed in Notes databases (LocalDomainServers and OtherDomainServers). Early in the Notes deployment, the only issues you need to resolve about groups are the standard groups that you are going to support for administrative purposes. These groups will be included in every database's access control list. It's best to create your default administrator groups before you have too many databases.

Another important step in your deployment, creating standard groups, is covered in Chapter 5, "Building a Deployment Plan," in the section "Step 6: Develop Standard Operating Procedures."

This step is complete when you have developed guidelines for naming people, servers, and groups. These guidelines should be available to all people responsible for creating or certifying ID files.

Step 12: Name Your Notes Domains

One of the most confusing concepts in Notes for many people is that of a domain. A domain is a logical collection of servers. The servers can be running on multiple networks, at multiple sites, including international sites. Users within a domain can be using different certificates, operating systems, and naming schemes.

Domains are often confused with certificates. The confusion arises because most organizations use their company name for their domain and the company name also appears in their certificates. Certificates and domains are two entirely separate concepts. Certificates are used in authentication and are a security measure. Domains have nothing to do with security. It is entirely possible to protect servers within a single domain from each other. You can change a domain name without recertifying users and servers, or recertify uses and servers without changing the domain name.

Each domain has a single Name and Address Book that contains all the entries for all people and servers within that domain. This makes sending mail to people within the same domain more convenient than sending mail to a different domain. To address mail to someone within the same domain you need only specify his or her distinguished name. To route mail to users in other domains, you have to specify not only the distinguished name, but the domain as well. For example, any user within the Cat Stuff domain wishing to send mail to Les Linko, a user in the Cat Stuff Domain, would type

Les Linko/Toys/Cat Stuff
in the recipient field. Someone from the Dog Stuff domain would have to type
Les Linko/Toys/Cat Stuff @ Cat Stuff
Having multiple domains implies that you will be managing multiple Name and Address Books. There is only one advantage to having multiple Name and Address Books; you can manage more than 50,000 users. If you are going to have more than 50,000 users within a single domain, you should consider creating more than one domain.

I recommend creating one domain for your production data servers, one domain for your application developers, at least one test domain (three if you're builing inter-enterprise applications), and an external domain. Some people will also choose to have an international domain, although that isn't necessary. When naming each of your domains, you should provide short, meaningful names. The names that you use for your test domain and application-development domain aren't as important. For example, it is easy to use AcmeTest or AcmeDev.

This step is complete when you have a list of named domains for your organization.

Step 13: Name Your Notes Networks

As with servers, naming your networks is an easy-to-overlook aspect of your Notes design. However, the names that you give your various networks have implications for other aspects of Notes. The key decision that you will face in creating the names of your Notes networks is when to have one network and when to use multiple networks.

You should pay particular attention to the naming of your networks. First, you need to understand how Notes uses your network names. All servers listed on a particular network have to be able to talk to each other using a single protocol. All servers grouped into a single network should be physically available either on the same LAN or through a bridge. Servers available only through dial-up or that require a second protocol to communicate can't be part of the same network. For example, three servers on a LAN all set up to connect with TCP/IP can be within the same network, although they need not be. See Figure 9.6 for servers on a single network.

Figure 9.6.
Notes server on a common network must be able to communicate using a single protocol.

Servers within a network instantaneously route mail to other servers on the same network. Servers on separate networks must have connection documents set up in the Name and Address Book. The connection documents list the times and criteria that determine when a connection will be made to route mail. Servers within the same network are visible to users in their server lists in the File Open Database list box. If you have a large number of servers, even if they are all on the same LAN, you should consider creating separate networks. List the production database servers on one network and other types of servers on a separate network. For example, if you have a large number of servers at your headquarters location—some backup servers, some passthru servers, some hub servers—it can be confusing to users to see all these servers listed in their File Open Database list box. Users shouldn't be accessing databases directly off these servers. Any server that shouldn't be directly accessed by users should be set up on a separate network. For networks that share a LAN, set the connection documents to route mail when a single piece of mail arrives.

Use a combination of your geographic location and network type when naming networks; for example, BostonNetBios or ColumbusNetware.

Using One Network Name

In today's world of wide area networks, bridges and routers are extremely common. This gives you the option of having servers in remote locations being physically available over a common protocol. So, for example, you may have a server farm in Columbus, Ohio and another server farm in Milwaukee. The LAN in both of these locations could be connected via a bridge, giving you an option when naming your Notes network to include servers at both of these sites on the same Notes network.

Advantages of using one network name:

Disadvantages of using one network name for your entire Notes network:

Using More than One Network Name

If you need to have more than one network name, I recommend choosing a different network name for each geographic location, even when those geographic locations are connected via a bridge or router. Using multiple Notes networks, the users see only those servers in their File Open Database list box where the vast majority of their data should be located. Because users don't see servers on the other side of the bridge or router, you can manage traffic through your bridge or router. Figure 9.7 shows multiple LANs divided into multiple Notes networks.

Figure 9.7.
Using multiple Notes networks to reduce traffic over a bridge.

Probably the most significant advantage to having multiple Network Names in a WAN environment is that you can manage the messaging traffic that Notes generates. In most cases, the traffic isn't significant but, if you are saddled with numerous slow links that are heavily used, you can schedule message routing periodically, allowing you to control what I call the "spill" level (that is, the number of waiting messages that will cause the server to route regardless of the schedule).

One disadvantage to this approach is that the mail router doesn't know about servers on other LANs until you add a connection document. You need to set up a connection between at least one computer on each LAN. In figure 9.7, one connection document is used to link Server A to Server B. All mail traffic between these two Notes networks goes through A and B. You don't need to set up a connection document between every pair of servers.

Also, you will be limiting the databases that users can access. Because users can't directly access servers in other Notes networks, you will need to create replicas of common databases at each site. The exception to this rule is servers in a single protocol WAN environment. In this environment, users can access any server directly by choosing File | Database | Open and typing the name of the desired database in the dialog box.

This step is complete when you have divided your Notes servers into Notes networks. Each network should have a name and protocol specified.

Step 14: Name Your Notes Servers

At his point you should know how many servers you need and where they are being placed. Use the guidelines developed in step 11 to assign names to each server.

You have completed this step when every server has a name, a network, and a domain. You should be able to register the actual servers (create ID files, server documents, and so on) at this point.

Step 15: Choose Gateways for Mail, Fax, Internet, Etc.

These gateways are common to most installations. The products you choose depend completely on your requirements.

If you have more than one e-mail package, you know that keeping the directories of multiple mail products synchronized is a fair challenge that doubles the amount of administrative overhead. Routing mail reliably between two different mail products has also been a challenge. You will need to decide whether you are going to try to standardize on one mail package or support two mail packages. You don't need to use Notes mail. Notes can directly use any mail system that supports the VIM or MAPI protocols.

For many people, supporting multiple mail packages is unavoidable. If you are one of the unlucky ones, you will have to install gateways between the two mail systems. There are already off-the-shelf gateways connecting Notes to virtually every other mail system. Notes is now the closest thing to a global mail hub that exists in the marketplace. You can route mail into or out of Notes from virtually any other product or destination, including the Internet, Microsoft Mail, IBM Profs, and MHS. You will need to get copies of competing gateways and evaluate them according to their ability to minimize your administrative time, keep directories synchronized, and support MIME and other mail standards.

In addition to mail gateways, you may want to consider setting up fax and Internet gateways. If you have a particularly large volume of mail going to and from the Internet, you may need to use special configurations to support the load. The key strategy is to split your inbound and outbound gateways.

When this step is complete, you should be able to draw a complete diagram of your Notes network. The diagram should include each server, printer, and bridge. Each server should have a hierarchical name, a network name, and a domain name assigned. Links to other systems should be shown.

Step 16: Assign Users to Home Servers

In Notes, each user must have a home server. I recommend assigning a secondary home server as well. The secondary home server is used when the primary home server is down. A mail server can handle, depending upon usage, anywhere from 100 to 500 users. The maximum load that you can place on a mail server is completely dependent upon the peak simultaneous usage. Chapter 7, "Determining Hardware and Software Needs," provides detailed information on sizing mail servers. Chapter 14, "Administering Notes Mail," has more detail on administering Notes mail.

The home server is the user's mail server. Using a dedicated mail server (discussed in Chapters 7 and 9) makes this step trivial. Simply assign users to the closest mail server, remembering to balance the load in locations that have more than one mail server. This step must be completed before installing the pilot application.

This step is complete when you have assigned every pilot user to a home server. This is just a planning step. You will use this information when you create ID files for users. You don't need to create the actual user IDs until you are ready to roll out an application.

Summary

Designing your Notes network correctly is a key step in minimizing your administrative overhead over the long haul. Designing your Notes network isn't the first step in your deployment plan. Before designing your Notes network, make sure that you have done an accurate assessment of your enterprise, and have some basic idea of the types of applications that you will likely develop. Once you have done your assessment, designing your Notes network can be fairly straightforward.

When you are done designing your Notes network, you should have

The next step after designing your Notes network is to develop your standard operating procedures. From there you move on to building your applications. When you are ready to build your applications, plan to exercise your Notes network early on and gather feedback on the quality of your Notes network. Set up your Notes network with growth in mind, but use feedback from your actual experiences early on to tune or change your Notes design.
Previous Page Page Top