Considerations for a new Domino Deployment
When evaluating your existing environment in order to plan a new deployment of Domino, the process is essentially the same as for an existing Domino infrastructure upgrade which is described in the next chapter. The additional concerns include:
- Designing your Domino architecture
- Planning your hierarchy
- Determining your organizational structure
- Setting your naming standards
- Defining your topologies
- Mail routing
- Planning your administration strategy
- Centralized or regional
- User management
- Server management
- Application management
Considerations for upgrading an existing Domino infrastructure
In addition to the general areas of concern listed in this section, when you are evaluating an existing Domino infrastructure, there are some additional areas to be reviewed and evaluated. You should evaluate your current Domino environment thoroughly when planning your upgrade.
- Some things you should consider include:
- Domain and directory configuration
- The number of domains you have
- The types of domains you have
- The types of directories in use
- Mail routing topology
- Replication topology
- Application topology
- User and server registration process used in your organization
- Naming standards for users and servers
- Domino certificates for organization and organizational units
- Domino software upgrade procedures currently used in your organization
- Hardware age and capacity
- Usage patterns on each server
- Template customization
- Third-party software
- Virus scanning
- Spam scanning
- Mobile device support
The goal of the review of your existing Domino environment is to understand whether it is meeting your needs and how close to capacity your environment is. Typically, older enterprise deployments have grown organically and incrementally, as the needs of the organization have changed. Growth in the size and maturity of an organization, mergers, acquisitions, and divestitures all have an effect on deployments, with changes typically being tactical and incremental, rather than strategic.
When reviewing your Domino environment, you may find a need for some new hardware or added capacity. You may also see an opportunity for server consolidation. For information about consolidating your Domino environment, see Domino 7 Server Consolidation: Best Practices to Get the Most Out of Your Domino Infrastructure, REDP-4181-00, which can be found at the following URL:
Considerations for upgrading existing Mail Servers
For many organizations, e-mail is considered a mission-critical application. For this reason, special attention should be given to the evaluation of your mail infrastructure. When assessing your Domino mail servers, you should consider each of the following areas:
- General server performance
- Average and peak CPU utilization
- Average and peak memory utilization
- Average and peak transactions per minute
- Average and peak disk utilization
- Total disk usage for mail files
- Average mail file size
- Largest mail files
- Current quota practices
- Current archiving practices
- Average number of messages processed each day
- Average number of concurrent users
- Peak usage times
- Usage of local replica model
- Inbox size
- Attachment compression
- Design Compression
- Standard settings and configurations
- Use of Web-based mail
You are probably already monitoring many of these things, and you may have historical data to show you how disk space usage and CPU utilization has increased over time. You may also track your top 10 largest mail files, and track the overall disk footprint of mail files on your servers. You may even have implemented an archiving and quota strategy to keep your mail files at or below a specified size, as well as a local replica model to improve user experience and decrease user impact in the event of network or server issues.
Wherever you are today, understanding the work that your mail servers do is a very important part of assessing your overall Domino environment.
Considerations for upgrading existing application servers
From a similar perspective, you should consider your application servers carefully. In some ways, your application servers are more difficult to assess than your mail servers because of different usage patterns and differences in application design. However, many of the same things should be assessed in your review. Information to collect while assessing your application environment includes:
- List of all application servers in your environment
- List of any mixed-use servers (mail and application)
- Locations of critical and enterprise-wide applications
- List of servers dedicated to a specific application
- Inventory of all non-mail applications
- Usage patterns
- Critical and enterprise-wide applications
- Application servers
- Use of Web applications
- Replication topology
- Attachment handling
- Any specialized functions or features used by applications
- Backup methodology
- Dependencies between databases in complex applications (such as lookups)
- Use of applications to send mail
Using the database catalog on your application servers, or on any server on which you allow users to create databases, is a good way to develop your application inventory. The catalog also provides information such as ACL listings and information about reads and writes on the database. Additionally, you can redirect the output of a directory list command on the operating system to develop a list of all databases and applications on your servers.
Because of the varied nature of applications, there may well be other concerns as well. It is important to work closely with your development teams to gain a full understanding of your application environment.
Historically, upgrading a Notes/Domino environment have had minimal impacts on existing Notes applications. While trying to provide improvements based on widely adopted open standards, keeping backward compatibility has always been very important. But just like for the messaging, applications need to be properly planned as well during an upgrade.
First, we can start thinking about applications from the outset. There's a lot of work that can be done prior to the actual upgrade. You will need all the details of your existing applications when discussing requirements and architecture.
You can start by doing an inventory of your applications. Leverage this opportunity to clean up your environment of unused applications. During this process, gather the following information:
- Application owner(s)
- User population using this application (executives, managers, departments or the entire organization)
- Type and level of complexity of the application (template-based, custom, back-end connectivity and integration)
- Importance of applications (mission-critical, company-wide, departmental, financial, data repository, etc)
- Existing Issues – This will avoid any blame on the upgrade if it was already broken
Then, you will need to determine what you will do with them. Some applications might be simple enough to upgrade their design directly, while others might require more testing and fixing their existing issues before the upgrade.
It is strongly recommended to plan your upgrade in small steps:
- Give a higher priority to the applications that must be fixed before the upgrade and assess the resources and efforts necessary for this task.
- Focus your efforts on the issues that are easy to fix, while avoiding the introduction of new features
- Upgrade the application that are based on standard templates, notify the users and assess if training would be necessary for them
It is strongly recommended NOT to upgrade applications and application servers if they are already having issues. Fix the existing issues before you attempt an upgrade.
When you do application testing, the key is to do it intelligently. You do not need to test every single application in your organization. Leverage your application inventory and the information you've gathered earlier, based on complexity, importance, and audience. Then, build a sample list like the following example:
- Mission-critical applications
- Applications used by executives
- Complex/Custom applications relying on backend or third-party software
- Applications based on the same standard template
It is critical to document your findings and to inform the application owners. if possible, leverage existing tools to assist you in your testing.
To guide you in your efforts, use your priorities and test results:
- Find the most important items that must be fixed before the upgrade
- Build a small team to test low-priority applications to identify unforeseen issues after the upgrade
If you have not done it already, install a Domino 8.5 server in your test environment dedicated for application testing. This server will be used for acceptance testing. After every successful application testing, it is recommended to archive copies of new templates.
If possible, it would be good to have a pre-production / quality assurance server where pilot users can actually use the upgraded application, just like in production. Make sure you document and resolve new issues encountered. It is recommended to wait until the upgrade is fully completed to implement new features, in order to avoid too many changes implemented at the same time.
Third party applications
Like many organizations, you may have third-party applications in place in your environment, such as anti-spam, anti-virus, backup, and monitoring. When reviewing your Domino environment, it is important to fully understand the third-party applications you have in your environment.
Things to consider while assessing the use of third-party applications in your environment include:
- Which third-party applications you have in place
- Versions of each third-party application
- Dependencies for each third-party application
- Interaction between Domino and third-party applications
There may well be other concerns, depending on the nature of the third-party applications you have in place. Because of the variety of applications and vendors, it is important to work closely with the teams supporting these applications to fully understand their usage in your environment.
When evaluating your environment, you should also consider any customizations that you have made to templates. It is possible that customizations have been made to mail templates, directory templates, and application templates that ship with Notes and Domino, such as teamroom and discussion. You need to consider any customizations that have been made, and determine whether any customizations need to be carried forward into the templates that ship with Notes and Domino 8.5.
If you do have template customizations, best practices suggest that you create a new custom template based on the template that ships with the version of code you deploy. This may involve re-coding certain changes to ensure full compatibility.
For more information about considerations for template management, see Domino Server Deployment Best Practices