Lotus Domino is the granddaddy of groupware systems. Matching Exchange in overall deployed seats and exceeding it in large organizations, Lotus Domino may not have the mindshare of Exchange, but it certainly has the market share. If you want to deploy a groupware solution for your organization, or migrate from another platform, Domino is a great choice, but you must carefully plan and prepare before running Setup.
One of the biggest mistakes that people make when designing a Domino implementation is not adequately planning. For example, suppose you determine that a dual-processor server will be adequate for one of your offices. It might seem logical to buy a dual-processor server. However, this may not permit future growth of the organization.
If you determine that a machine with two processors will get the job done, I recommend buying a server with four processors. If budget is an issue, consider buying a server that supports four processors, but has only two processors installed.
Likewise, if you determine that 2 GB of RAM will be sufficient, you probably don't want to buy a server with a system board that supports only 2 GB of RAM. It would be better to buy a server that can utilize more RAM, even if you don't fill the server's memory slots to capacity right away. Remember that, in the long run, it's less expensive to buy a more powerful server than you actually need than to buy a server that only meets your current needs and then have to replace the server a year later.
Another big mistake that I frequently see organizations make when deploying a groupware system is believing the benchmark numbers provided by hardware manufacturers. I'm not saying the hardware manufacturers are lying about the numbers, but you must remember that a manufacturer’s goal is to sell as much hardware as possible.
To get the best possible numbers, manufacturers will typically use server configurations that are much different from what would be used in the real world. For example, during benchmark testing, a manufacturer would typically disable all services that are not absolutely necessary. Domino would probably be running a minimal configuration as well so features such as full-text indexing would likely be disabled. My point is that although benchmarking is a good guideline, don't accept it as the gospel truth.
Determining your company's server needs
When planning the hardware that Domino will run on, you must consider several factors. Obviously, you must take into account Domino's minimal hardware requirements and the number of users that each server will support. You must also take into account how your users will use the server. For example, mobile users will place a different set of demands on the server than desktop users.
You must also consider whether users will be using only mail and calendaring applications or if they'll be running other Domino applications as well. Finally, consider concurrency—the number of users who will access the Domino server simultaneously. According to the IBM Web site, a concurrency rate of about 35 percent is fairly typical.
I recommend beginning the process of determining your company's server needs by making a series of drawings. The first drawing should be a layout of your company's offices. Next to each office, list items like the total number of users that will use Domino and the expected number of concurrent users.
Also list what server applications will need to be run. Primarily, you'll want to focus on Domino applications, but if your Domino servers will be running other applications, such as server management or monitoring utilities, include them in your list.
Keep in mind that this drawing focuses only on the needs of each office. It doesn't yet address whether a server should be placed in each office. You haven't yet compiled enough information to determine server placement.
Before you can effectively determine placement, you need to add to your drawing the data links between each office. For example, if you have a T-3 line connecting your Miami and Las Vegas offices, draw a line between the two offices and label the line as a T-3.
Once you've completed your drawing, the next step is to figure out your server requirements and placement. Obviously, this will differ from organization to organization, so I can't tell you what should go where. What I can tell you is to use common sense.
For example, if you have 1,000 Domino users in your main office and you have a branch office that's connected to the main office by a T-1 line and has 10 employees, you probably don't need a server at that branch. Why dedicate an entire server to support 10 employees when the infrastructure exists to allow those employees to connect to the corporate office? On the other hand, if a branch office has 50 employees and a relatively slow link to the main office, you'll probably want to place a Domino server in that location to minimize traffic across your WAN link.
IBM isn't very specific about Domino's system requirements. IBM's bare minimum recommended hardware for running Domino 6 is a Windows 2000 Server with 256 MB of RAM and 4 GB of free hard disk space. You'll have to add more resources based on the applications and the number of users your server will be hosting. Plan on dedicating a bare minimum of 75 MB of disk space for each Domino user. IBM has a Workload Estimator that will help you plan for your server hardware needs.
Design a hierarchical naming scheme
The next step is to create a hierarchical naming scheme. If you've ever designed an Active Directory structure, you'll find this process similar. The idea behind this process is to sketch an organizational chart of your company. Later, when you begin creating objects, you can place those objects within the organizational hierarchy and the object's names will reflect their position.
Domino uses the same directory structure as Microsoft’s Active Directory. An object can have a Country (C), Common Name (CN), an Organization (O), and one or more organizational units (OU).
As an example, suppose you had a company named Widgets Inc. that existed entirely in the United States. The company has an East coast and a West coast branch and each branch has HR, accounting, and marketing departments. Now, imagine that you have an employee named John Smith in the accounting department of the West coast branch.
In such an organization, the Country would be U.S. and the Organization would be Widgets. You'd probably have two Organizational Units, one for the branch and one for the department. In this case, one OU would be accounting and the other would be West.
The full directory name of the user object would look something like this: CN=John Smith/OU=Accounting/OU=West/O=Widgets/C=US. Notice how the full hierarchical name moves from most specific (user name) to least specific (organization and country).
Plan your Domino domain structure
Next, determine your Domino domain structure. In Domino, a domain is a set of servers that share a common administrative staff. Books have been written about the philosophies behind creating Domino domains. To summarize: If the same people will be administering every Domino server in your organization, you only need one Domino domain. If your company is made up of independent business units and you need to make sure that each unit can administer its own Domino servers but no one else's, you'll create the domain structure accordingly.
Configure your DNS servers
There's nothing too mysterious about name resolution within Domino. In a Microsoft environment, calls to Active Directory are made through LDAP queries. These LDAP queries wouldn't be possible without the underlying TCP/IP communications, which, of course, rely on DNS being able to resolve the individual machine names.
Domino works very similarly. The only major difference is that instead of using the LDAP protocol, Domino relies on a protocol called NRPC. All of the underlying TCP/IP and DNS requirements are basically the same as they would be for a Microsoft Windows network. Remember that you're running Domino on a Windows 2000 server.
Pick a certificate authority
The next step is to decide which certificate authority to use. Domino and Notes require you to use a certificate authority for issuing and maintaining digital certificates. When you install Domino the first time, it will automatically create a Notes certificate authority that can be used to issue digital certificates to Notes clients.
Keep in mind that these certificates, although critical, only work internally. If you plan to secure Internet-based communications with SSL certificates, you must either create your own certificate authority or use a third-party certificate authority, such as VeriSign.
Set up your first Domino server
If you've planned properly, setting up your Domino server should be a fairly simple process. You'll have to make decisions along the way, such as the hierarchical naming conventions and the domain structure, but the setup shouldn't give you any surprises.
Create additional certifier IDs
Next, you'll create additional certifier IDs. Domino requires each branch of the hierarchical naming tree to have its own certifier ID. At the top must be an organization certifier ID. This ID is automatically created when you install your first Domino server. It will be placed in the Domino data directory and given the name CERT.ID. This certifier ID is used to automatically certify the Domino server's ID and the Administrator's user ID.
Certifier IDs are also created at the OU level. You can have a certifier ID that's up to four levels deep. For example, Widgets Inc. would have certifier IDs for Accounting/West/Widgets, HR/West/Widgets, etc.
Set up recovery for certifier IDs
One of the most important steps in the entire rollout process is to configure recovery for the certifier IDs. Each object, OU, and the organization itself receive a digital certificate. If any of these certificates were to become corrupt, you'd have a major problem on your hands. If a user’s certificate were corrupted, the problem would invalidate that account. If the certificate for an OU were to become corrupted, you would have an entire section of your network suddenly become null and void.
Although much less damage is associated with user certificate corruption, neither situation is desirable. That's why it's so important to set up a certificate recovery location. This location will house an encrypted backup copy of every certificate issued. Technically you can create this location at any time, but I strongly recommend doing it before creating any more user accounts or Domino servers.
Keep in mind that after you have specified a recovery location, you must also designate which Administrators are allowed to recover certificates. Initially, there will only be one Administrator (you). As you create more administrative accounts, they're not automatically assigned the right to recover certificates. This right must be assigned manually. If you don't like the idea of too many people being able to recover certificates, you can increase security by configuring Domino so that multiple Administrators must work together to recover a certificate.
Register additional servers
Now that the first server's setup is complete, you may begin adding servers to the Domino organization. The procedure for doing so will be very similar to what you've already done. Once the servers are in place, you'll take several additional steps before turning users loose on the system, though. As you create servers, don't forget to apply any patches or service packs that are available. Remember that Domino rides on top of Windows 2000, so you'll apply both Windows and Domino patches.
First, create all of the necessary administrative accounts. You should also create one or more administrative groups and assign these groups administrative permissions to the necessary databases and other resources.
You'll also finish building the Domino environment. This means installing Notes and other Domino applications. You must also configure any necessary connectors, modems, and RAS links, and then configure mail routing to use these various connections. Then you'll set up a replication schedule and configure the Notes servers to handle inbound and outbound SMTP mail.
The next step that I recommend is figuring out how you plan to back up the Domino organization. Remember that while there may not be anything to back up at the moment, it's better to get a backup mechanism in place and test it now than to wait until you have live data on the server.
Once your backup plan is in place, start developing the policies and procedures that your users must adhere to. After implementing all of the various security policies, consider creating some test accounts and playing with the accounts for a week or two to make sure that your policies work correctly. During this testing period, try to violate the security policies and break into the Domino system. This will help you discover weaknesses in your policies. Once you complete the testing period, you'll be ready to begin creating and issuing user accounts.