— 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:
-
Identify supported desktop platforms.
-
Identify supported server platforms.
-
Identify supported network protocols.
-
Develop a WAN strategy for remote access.
-
Decide the location of servers.
-
Identify your replication architecture (network topology).
-
Size the hardware for desktop and servers.
-
Identify current IS systems that must integrate with Notes.
-
Identify current desktop applications that must integrate with Notes.
-
Decide which application-development tools to support.
-
Create naming guidelines for people, servers, and groups.
-
Name your Notes domains.
-
Name your Notes networks.
-
Name your Notes servers.
-
Choose gateways for mail, fax, Internet, etc.
-
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
-
In-house availability of support skill
-
Small organizations standardize on one platform
-
Large organizations should have no more than two platforms
-
Don't change platforms just to use Notes
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:
-
In-house availability of support skill
-
Small organizations standardize on one platform
-
Large organizations should have no more than two platforms
-
Don't change platforms just to use Notes
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):
-
In-house availability of support skill
-
Small organizations standardize on one platform
-
Large organizations should have no more than two platforms
-
Don't change platforms just to use Notes
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:
-
WAN connected workstations—the same connectivity as a LAN but often slower
and more expensive (this option and the next provide direct access to Notes
applications, no replication involved)
-
WAN connected Notes servers—allows local, fast, cheap access to users local
to the server and allows control over the usage of WAN bandwidth through
routing and replication schedules
-
Dial-up connected Notes servers—same as WAN connected Notes servers, but
uses phone lines or other "on demand" connectivity for scheduled routing
and replication.
-
Dial-up connected workstations—each individual connects to a remote Notes
server to route and receive mail and to replicate any local replica databases.
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:
-
Which databases does this site need to access? How many hours per day/week
are the databases going to be accessed? What is the total throughput required
for all users at the remote site?
-
Is there a high-speed connection in place? If so, is there enough bandwidth
to support your Notes applications? Notes itself places very little overhead
on a network, so you simply need to eveluate the load placed by your applications.
-
What connection speed do you need to support a remote site? A remote site
with two or three users will have different bandwidth requirements than
a remote site with 25 to 30 users. Your connection options include (but
aren't limited to)
Leased T1 lines. T1 lines offer enough throughput to support
nearly any remote site. Fractional T1s are also available.
ISDN lines. ISDN lines aren't much more expensive than an ordinary
phone line and offer 56Kb throughput. Multiple people can share an ISDN
line. With ISDN, users will experience a delay of a few seconds while a
call is placed, but performance after that shold be acceptable for any
text-based application.
Modem. Get at least a 28.8 modem for each user.
Internet. Remote sites that must place a long distance call
can consider replicating over the Internet, using ISDN lines or ordinary
phone lines.
Private networks. Network companies such as CompuServe can connect
your headquarters and remote sites at a very competitive rate. Dial-up
and frame-relay connections (just to name two popular options) are available.
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:
-
Timeliness of data. The user gets the latest data without having to wait
for a scheduled replication to her remote server.
-
You save the expense of placing a remote server. This expense includes
the cost of the hardware and the extra administrative burden.
These are the advantages of placing a server in a remote office and replicating
databases:
-
Users accessing replica copies generally get better performance.
-
Users can continue to work when the network is down.
-
You keep control over replication. If you don't place a server in a remote
office, one thing that can happen is that people in the remote office create
their own replicas. If you have five people in a remote office, you can
end up with three or four of them each having their own replica of a headquarters
database. Each worker can end up with a slightly different version of the
database, and phone costs skyrocket as each user replicates the entire
database. You may not save on hardware or support costs by not placing
a remote server. Your overall goal should be to minimize the number of
servers, but you must consider carefully the needs of your users.
The following list shows the disadvantages of having your users dial directly
into headquarters:
-
The cost of the phone lines and the connection charges users incur when
calling headquarters can add up quickly.
-
Modems are some of the most troublesome components of a Notes network,
requiring a higher percentage of administrative time than users connected
locally to their own servers. Setting up a remote server with a single
multi-port modem may save time troubleshooting modem problems.
-
Performance over a 28.8 modem can leave something to be desired. Make sure
that the performance of online access is within acceptable limits. You
may need to price out higher bandwidth connections or place a remote server
if performance is unacceptable.
-
A remote-site coordinator is needed for each site with a Notes server.
The availability of trained personnel can limit your ability to place remote
servers.
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:
-
Your connection documents are easier to manage.
Connection documents on your spoke will be small variations on a theme.
Thus, your procedures for adding a new spoke server are almost error-free.
-
Server schedules are easier to develop and maintain.
A server schedule based on a hub-and-spoke architecture is easier to
maintain than a schedule based on an architecture where all machines are
connecting to all other machines. Because the hub encapsulates your total
replication schedule, you can more easily chart and manage your total server
schedule.
-
It's easier to track the performance of your servers when you use hub-and-spoke
architecture.
Replication is a hog. If you replicate between servers frequently,
your online users will definitely notice when a replication is in progress.
Having all the spokes constantly dialing each other can lead to a large
replication load and unnecessary replication on your network.
-
A hub-and-spoke architecture is more reliable.
Not only are the connection documents easier to set up, but replication
problems are reduced. If you have many servers trying to replicate with
a particular spoke server, it is possible that Notes will lose a replication
request, causing data to not be replicated between those two particular
servers.
Even 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:
-
At least one dedicated mail server (can handle 75 to 500 users)
-
At least one dedicated hub server (hub-and-spoke networks only, can handle
5 to 20 spokes).
-
At least one production database server
-
A server for external domains
-
A backup server
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:
-
Don't install underpowered configurations.
-
Install enough memory.
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
-
Decide whether you have a compelling reason not to use hierarchical names.
If not, use them!
-
Develop a list of organizational unit certificates (for use with hierarchical
names only)
-
Develop guidelines for naming users
-
Develop guidelines for naming groups
-
Develop guidlines for naming servers
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:
Andrew Dahl/Publishing/L3Comm
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.
-
Common name. Your common name is your first name, last name, and
perhaps a middle initial.
-
Organizational unit. Organizational units quickly identify the department
or geographic location of the person. A hierarchical name may use more
than one organizational unit within a single name. Examples of organizational
units are North America, Europe, Marketing, Sales, New York, or perhaps
a combination like Sales/New York.
-
Organization. The organization name is typically the name of your
business. For example, Acme, IBM, or L3Comm.
-
Country name. Country names are an optional part of hierarchical
names and aren't used very often. A country name is a two-letter abbreviation
for a country. Before you use a country name, you should register your
organizational name with the clearinghouse of other X.500 names within
your country. You can view current X.500 names and register yours by using
the World Wide Web at http://gopher.gsfc.nasa.gov/services/email/x.500.html.
Use country names only when you are very concerned about the complete uniqueness
of your names on a worldwide basis, both within and outside your organization.
Two examples of country names are US for the United States and CA for Canada.
You combine these units in each component of a distinguished name with
slashes. Example of valid distinguished names:
Scott Comeon/Columbus/Publishing/QuickCon
Mike Crashwell/Development/HAL
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:
-
Each user and server can have a unique name.
-
Hierarchial names provide a clue as to the role of a person or server
within your organization.
For example, John Doe by itself gives no clue as to whether John delivers
or is the CEO for the organization, but John Doe/Marketing/Acme clearly
identifies John as a member of the marketing staff. The same is true for
servers that have hierarchical names. For example, Mail/Marketing/Acme
is clearly the mail server for the marketing department at Acme.
-
Hierarchial names allow the use of wild cards in your access control
lists.
For example, if a database has the name John Doe/*/* in the access
control list, or in a group listed in the access control list, both John
Doe/Ohio/Acme and John Doe/California/Acme have the same level of access
to that database. However, the use of distinguished names within an access
control list, for example John Doe/Ohio, means that John Doe/California
would have no access to that data. If you have a database that should only
be accessed by the marketing department, you can put */Marketing/Acme in
the access control list and only people who are in your marketing department
will have access to that database (assuming that the default access is
no access).
-
Using hierarchical names allows you to use hierarchical certificates, which
have several advantages over the use of flat certificates:
-
Hierarchical certificates enable decentralized management of your Name
and Address Book. (You can still centrally manage your NAB if you want.)
To use hierarchical names within your organization, you need to create
a certificate for each organizational unit. You start with an organizational
level certificate, Acme, and then add several organizational unit certificates:
Marketing/Acme, Product Development/Acme, Research/Acme. The organizational
certificate is kept in a secure place, and the organizational unit certificates
(stored in certifier ID files) are handed out to certifiers within the
various departments. Thus, hierarchical certificates, by allowing you to
create certificates for each department, enable you to have multiple people
involved in the management of your Name and Address Book.
Contrast this with flat names, where there is only one certificate
in the entire enterprise—the organizational certificate. In this case,
anyone with access to the organizational certificate can create any name
he wants, and give himself complete access to any data within your organization.
People with access to organizational unit certificates can only create
names that match the name of the organizational unit certificate. For example,
using the certificate Marketing/Acme, a certifier could create the user
ID Jerome/Marketing/Acme but not the user ID Jerome/Sales/Acme. User IDs
certified with an organizational unit certificate will inherit the organizational
name that is part of that certificate.
-
Hierarchical certificates allow you to react quickly in case of a compromised
certificate.
Because your users are all certified with a particular organizational
unit certificate, and different users are certified with a different organizational
unit certificate, fewer people will have to be recertified when a certificate
is lost or stolen. If an organizational unit certificate is compromised—that
is, falls into the hands of an untrusted party—only those users who have
been certified with that particular organizational unit certificate need
to be recertified. Don't forget that you also need to recertify servers
that have been certified with that particular organizational unit certificate.
Step-by-step instructions to recertify users and servers are included in
Chapter 16, "Administering Notes Servers."
-
With hierarchical certificates, you can create a deny-access entry in
your server document to prevent any user IDs certified by a compromised
certificate from accessing the server.
Contrast this with a flat naming scheme when an organizational certificate
is compromised. In this situation, all users and all servers throughout
the entire organization must be recertified. This is a much larger job.
-
Hierarchical certificates allow users within an organization to verify
each other's identities.
Using hierarchical certificates or organizational certificates that
all descend from a common organizational certificate means that all users
within an enterprise share a common certificate, namely the organizational
certificate. Because they share a certificate, they can authenticate each
other's identities with no further administrative overhead.
Contrast this with having multiple flat certificates within an organization.
This case could arise in a large enterprise where you have multiple pilots
that have grown into multiple production spheres. When you have multiple
flat certificates in an organization, in order for a user from one to authenticate
a user on another, one or the other user would have to be certified with
the other person's flat certifier certificate.
-
Hierarchical names give you tight control over external access to your
databases.
If the sales department certifies a customer server, allowing that
customer server to access the sales department's server, the customer doesn't
automatically gain access to any other server in your organization. The
customer only can access servers certified by the sales certificate or
by a descendant of the sales certificate. A server certified by product
development couldn't be accessed by this customer.
Figure 9.5 shows the servers that could be accessed by an external
server certified with a hierarchical certificate.
When using flat certificates, an external server certified by your
organizational certificate can access any of your internal servers.
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:
-
Hierarchical naming requires planning. Perhaps the largest disadvantage
to using hierarchical names is the up-front planning that must go into
creating the organizational unit certificates. The quality of this up-front
planning greatly determines the amount of downstream administrative burden
required to maintain your Notes installation. Careful planning is a must,
but you must balance the time spent on planning with the need to get your
first pilot applications done as quickly as possible.
-
Hierarchical naming results in having to recertify users when they transfer.
See the next section, "Creating Hierarchical Certificates," for a discussion
of ways to minimize this burden.
-
When you deal with many distinguished names, the screen can get cluttered.
Applications that you design that display names should parse the hierarchical
name to display only the common name for that particular user. Application
design and construction may take slightly longer when using hierarchical
certificates.
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:
-
Use names that meet the requirements of your network.
If you are using TCP/IP, your server name should be identical to your
TCP/IP host name. In this case, you are forced to take into account all
the needs of your Notes topology when creating your TCP/IP server names.
-
Avoid spaces and underscores in server names.
As a practical matter, it's easier for an administrator (who will be
typing the name of a server quite often) to avoid typing spaces. It's also
good to avoid having any names in your system that use underscores, as
underscores are translated by gateways into other characters.
-
Use simple names.
If yours is an international enterprise, your server names aren't translated
when they are transmitted to international sites. Keeping your names simple
will help your international users understand the purpose of those servers.
-
Use separate names for different types of servers.
When designing your Notes network, you will be assigning servers to
particular tasks. For example, all but the smallest installations will
have a separate server set up to hold mailboxes. In addition, you likely
will be setting up hub servers for replication purposes and dial-up servers
to help support remote users. You may be dividing your production data
servers into different categories, based on department or type of application
supported. The names of each of these servers should imply the type of
server. For example, a mail server may be called Mail 1/Acme. A dial-up
server could be called Passthru/Acme. Pay particular importance to server
names that will be visible outside your organization. This includes all
servers in your external domain. Use a name that reflects well on your
corporation. Avoid cutesy names, such as those named after people's dogs,
places of birth, or favorite artists, unless the whole organization is
willing to use one scheme (for example, cartoon characters).
There is one disadvantage to naming your servers based on the type
of server. Changing the function of a server is difficult. This doesn't
in any way inhibit the growth of your Notes deployment. It's far more common
that you will simply add a new server to your network rather than change
the function of an existing server.
-
Avoid using names with underscores because Internet gateways translate
an underscore into a space.
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:
-
Your mail is routed instantaneously between these servers.
-
The location of the servers becomes transparent to the end users. The end
users are presented with a list of server names without regard to their
geographic location.
Disadvantages of using one network name for your entire Notes network:
-
The location of servers is transparent to your end users. This can cause
frustration when users select servers at a remote location when they could
be selecting servers at a headquarters site. This can increase traffic
over your bridge or router.
-
Traffic across your bridge or router increases, especially when you have
users browsing remote servers. Of course, you can always design your bridge
or router so that only your servers can use it to communicate. This restriction
may actually cause problems, as administrators often will need to manage
remote servers from their desktops.
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
-
Decided on platforms for clients and servers
-
Chosen a network protocol
-
All of your organizational unit certificate planned out and created
-
Created your server documents
-
Created guidelines for naming people, servers, and groups
-
Configured your replication topology
-
Completely updated your telecommunications network diagram with your planned
Notes servers and planned Notes connections
-
A clear plan for assigning users to individual servers, giving you some
feel for the number of users that you plan on supporting with each server
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.