Table of Contents | Next
Attention:
- Notes and Domino 8.5.3 shipped on October 4, 2011. It is recommended you upgrade to the latest version available and you can check the Notes/Domino Fix List for this information. The upgrade process has not changed from 8.5.2 to 8.5.3, but some resource information contained on this page has been updated for the new version.
This document contains the following sections:
Evaluate and monitor your existing environment
Taking the time to do a thorough evaluation of your starting point is time well spent. Capturing baselines of your existing server infrastructure will allow you to compare how the upgraded environment is performing.
Evaluate
- Do a thorough investigation of the current state (starting point) and use tools to facilitate data capture
- Server infrastructure (including baseline stats, performance, etc)
- Clients / workstations
- Applications
- 3rd party Products
- Document pre-existing conditions and problems
- Try to resolve outstanding issues and problems prior to upgrading
- No matter how tenuous the link, an upgrade can be held responsible for any problem whether old or new
- Document things you want or need to address while you have the opportunity, focus and resources available
-There is always cleanup that can be done ahead of time
Monitor
Monitoring is a critical part of any upgrade, even a point release upgrade. The goal is to understand your current cost of running the existing environment and to predict a problem before it happens in the new environment.
- This is really important when you are moving users and/or consolidating servers
Steps:
- Make sure you are capturing the available raw data from the servers
- Operating system capacity and performance metrics
- CPU, memory (usage, paging), disk (usage, I/O rates, performance), network
- Domino server specific statistics
- Other components (for example, SAN switches and disk metrics)
- Interpret/analyze the data and create your baselines for your current environment
- What are the typical operating parameters for your servers
- What is the data telling you about your environment?
- Execute your monitoring processes using your base lines
- Create your daily/weekly/monthly reports based on your baselines
- Create a remediation process based on outputs that exceed your baselines
Back to top
Evaluate operating system and hardware requirements for 8.5.x
System Requirements
- Should hardware refresh be included...
Additional Operating System information for Domino 8.5.x
Windows 2008
If Domino is started as a Service
- No Domino Console visible
- Domino Java Console can be utilized
- Extra icon Installed on Desktop for Java Console
If Domino is started as an Application
Windows 2008 R2 is now supported as of 8.5.2.
You may find the following information helpful during the upgrade process:
IBM i
You may find the following information helpful during the upgrade process:
AIX
You may find the following information helpful during the upgrade process:
Are you moving to a 64-bit operating system?
One major advantage to running Domino on a 64-bit operating system is the access to additional addressable memory space, even if running 32-bit Domino.
Are you upgrading from 32-bit Domino to 64-bit Domino?
If so, the following things will happen:
- All existing full text indexes will be discarded and rebuilt
- On Windows, all existing views currently built will be discarded and rebuilt
Because of the two items mentioned above, if the updall process is used during upgrading it will take much longer to run so you should plan for it. This is a one time occurrence.
See the following link(s) for additional information:
Back to top
Evaluate coexistence of features across versions
Clustered Servers
- Upgrading your clustered servers at different times is supported, so you can have a mixed 6.5.x and 8.x cluster during the coexistence period of your project.
- Keep in mind however that the cluster replication task will not restrict the replication of any design elements. The Domino Directory 8 design is backward compatible with Notes and Domino 6.5.x. Other databases may, however, cause issues on earlier Domino servers and Notes clients.
- If you want to keep design elements at the same version as the server, do not put Domino 6.5.x or 7.0 in the same cluster with Domino 8 servers.
Resource Reservations
- Resource Reservations has seen significant changes since Domino 6.5. Prior to Domino 7, the resource and reservation functionality was distributed amongst the resource template, the router task, and the schedule manager task.Beginning with Domino 7, this functionality was combined into a single server task: Rooms and Resource Manager or RnRMgr.
- If you are upgrading directly from Domino 6.5.x or earlier be aware that Resource Reservations databases (RRDB) based on a 6.x or earlier design do not function properly on Domino 8 servers.
- Overbooking of rooms and resources can easily occur if you attempt to use a pre-Domino 7 RRDB on a 7.0 or later server. So you’ll want to replace the design of the Resource Reservation template immediately.
Technote #1363903 - How to upgrade the R&R database from a Domino 6 to a 7 or 8 release.
Wiki article - Clustering the Resource Reservations database in Lotus Domino
Flat Certification
- Support for flat certification was removed in Notes and Domino 7.0, due to its inherent lack of security and its inability to be used with AdminP.
- If you are upgrading directly from Notes and Domino 6.5.x to 8 and are still using flat certification, you must convert all flat names to hierarchical names as part of the upgrade project
Policies
- Most of the new capabilities of Policies in Domino 7 and 8 will be ignored by Notes 6.5.x clients. For example, Policy lock-down settings will have no effect on 6.5.x clients, and the new types of Policy Settings (Mail, Productivity Tools and Activities) will also be ignored.
Back to top
Upgrade Domino on an existing machine or move to a new one?
As part of the Domino Server upgrade, you have a good opportunity to make some other changes to your Domino infrastructure. There are some choices you need to make at this point, such as if you want to upgrade an existing server or install a new server with a new identity, or install a new server and inherit identities. Here are some things to consider at this point in the process:
Will this be an upgrade or a new installation?
After defining your server requirements, you should determine if servers should...
- be upgraded in place?
- be replaced with new servers?
- be some combination of these approaches?
Should new servers inherit existing identities or have new ones?
Consider what impacts there could be on the client configuration.
There are a range of options depending on the answers to those questions above. For all options, the upgrade process and configuration testing needs to be done in a test environment first.
Option 1 - Upgrade the existing Domino server. This is the easiest approach.
- This is an "in place" software upgrade of an existing server
- The server identity remains the same
- No change of underlying hardware or operating system
- If clustered...
-upgrade one server at a time in the cluster
-remember that ACLS and replication settings do not prevent designs from propagating in a cluster
Option 2 - Move existing Domino Server to new hardware
Note: It is not recommended that you upgrade the hardware and Domino at the same time. You should upgrade the hardware before or after the Domino upgrade, but not at the same time unless you have no other choice. Upgrading them separately makes it much easier to troubleshoot when problems arise, isolating the issue to the hardware upgrade versus the Domino upgrade.
The server identity remains the same, but will be moved to a new machine:
- Bring down the current server
- Move all data to the new hardware to the same position (same file locations and directory structure) as the old hardware.
- Domino program directory
- Domino data directory
- Domino transactional logs
- Domino DAOS files (only if upgrading from 8.5 to 8.5.1)
Note: If you are changing file locations and directory structure during this move, refer to the wiki article: Changing directory locations when moving a Domino Server to new hardware for more information.
- Rerun install of the current version of the Domino server and point to all of the same file locations to mirror your previous configurations
- Once you start the copy of data to the new hardware, you should never bring up the server on the old machine
- Before bringing up the server for the first time, switch the server host and network identities to that of the old server
- Run this configuration for a few days to make sure everything runs correctly. If so, then you can safely upgrade this Domino server
Option 3 - Install New Domino servers (Inherit Identities)
- Build new server independently
- Create a new temporary server identity
- Permits change of underlying hardware and operating system
- Permits testing of the configured state before cut-over
- Create replicas on temporary server and keep in synch with server to be replaced via replication
- At desired time, switch server host, network and Domino server identities
- Change is transparent to clients
- If clustered...
-repeat process for each server
-do not add temporary Domino server into cluster
Option 4 - Install New Domino server (New Identity)
- Build a new server independently
- Create a new server identity
- Permits change of underlying hardware and operating system
- Permits testing of the configured state before cut-over
- For mail users, requires some migration of users and client configurations from existing to new server
- Permits monitoring as you ramp up users to verify that you don't overload the "new" server
- For applications, requires migration of applications to new server and redirection from old server
- If clustered...
- create new servers and new cluster
- migrate users and client configurations to distribute users across the members
- migrate applications to the new cluster
Back to top
Evaluate what's new in Domino 8.5.x
Can you eliminate customization by adopting a new feature?
Which features should be introduce...
- that help the upgrade?
- during upgrade?
- after completion of the upgrade?
What architectural impacts do new features have?
Do new features impact other infrastructure components?
What's new?
For full information about what is new in Domino 8.5, 8.5.1, 8.5.2 and 8.5.3, refer to the Notes and Domino InfoCenter
What's new in Domino 8.5?
- Notes ID Vault
- Notes Shared Login
- Domino Configuration Tuner
- Domino Attachment and Object Service
- Message Recall
- Document Compression
- Reduced I/O - update task
What's new in Domino 8.5.1?
- SPNEGO
- New Policy Management
- New Roaming options
What's new in Domino 8.5.2?
- Managed mail replicas
- Upgrading multiple databases to a new ODS
- Corrupt database collection
- DAOS enhancement for archived databases
- Space used column
- Domino Diagnostic Probe
NEW!! What's new in Domino 8.5.3?
Database Administration
- Technote #1501675: Purge Interval Replication Control (PIRC)
- Sort by mail subject, ignoring prefixes such as RE: and FW:
- Purge Index List prevents unnecessary Full Replication Searches when documents are purged by fixup due to corruption
- Updall -t "viewname" can now be run against directories and/or .IND files
- Improved updating of Unread Tables
Server Administration
Serviceability
Security
Entitlement
Compatibility
- Embedded Sametime version with Notes is 8.5.1 (make sure the Sametime server is configured for Client ID 1243)
- Embedded Symphony version with Notes is 3.0
Programmability
- New version of Dojo to be used for xPages
- FTSearch sorted xPages
What's been removed?
The following features are no longer available on Domino 8.5.x servers:
Single Copy Object Store (SCOS)
The same benefits should be provided by a combination of improvements in
- attachment consolidation (using DAOS)
- database design compression
- document compression
Refer to technote #1096686: How to disable shared mail in Lotus Domino
Direct dialup modem support (X.PC) connectivity
- The Domino Administrator 8.5.x can be used to configure and maintain direct dialup modem support on servers running pre-8.5.x releases of Domino only
NSFDB2 is Limited Availability
For customers who begin with IBM Lotus Domino 8.5.2, NSFDB2 will no longer be available. NSFDB2 will continue to function for customers running earlier releases of Domino that included it, but will require administrators to contact IBM Support and acquire necessary files to be added to the installation. For details, see the linked technotes.
If your organization uses NSFDB2 as of 8.5.1, refer to the following tech notes to learn how to maintain your support of the feature. If your organization does not use NSFDB2, you don't need to do anything.
Back to top
Create a server test environment
If you do not have a test environment already, it is highly recommended that you create one. You will want to incorporate all of the decisions that you have made up to this point and create a test environment that is representative of your current and target platforms, including hardware and software resources. Creating this environment is very important if you want to do any kind of performance or capacity planning.
For your basic test environment:
- Install Domino 8.5.2
- Create copies of applications
- Use test IDs and access applications just as you would in production
- Customization work would be done in test - get access to all of the templates and applications from your test server and customize them as needed
Back to top
Pilot the upgrade in the production environment
Consider the following when performing your production server pilot:
- Document EVERYTHING during your pilot upgrade. For example, you should record the detailed operation, detailed commands you type, the hours required to perform the upgrade, and any error messages you encounter.
- Imaging: Because some of the testing should focus on process aspects where a set of steps are to be executed, it saves a lot of time to be able to reset your environment to a known position. For example, VMWare with its snapshot capability can be a useful tool for this purpose. If VMWare is not ideal for your specific platform, implementing a robust backup and restore program is another way to achieve this.
- Determine feedback needed from pilot users and determine success criteria
- Choose pilot groups carefully. Start with immediate IT staff, then add lowest risk user populations. Grow the pilot population over time, adopting new audiences. Target diverse roles: technical, power user, assistants, application users
- Perform the upgrades necessary for the pilot. Start with Administration servers, Hubs and SMTP Gateways with no users. Begin your pilot with only one Domino mail server. Once working properly, continue to add/upgrade more.
- Run a steady state environment for a defined pilot duration
- Review and update procedures after pilot feedback
- Leverage clustering. If there are any issues during upgrading, your users can fail back over to the "down-level" server.
Back to top
Upgrade to release 6.5.x if the current Domino version is older
If you have a Domino Version prior to 6.5.x (4.x, 5.x, 6.0.x, 6.4.x) you need to decide if you want to first upgrade to 6.5.x before upgrading to 8.5.x.
Important Notes:
- IBM only certifies upgrading from Domino 6.5.x or greater to 8.5.x directly.
- Domino 6.5.x has reached End-of-Support. If you have this or an earlier version, you need to upgrade as soon as possible. To keep track of supported versions, visit the Software Support Lifecycle page.
You may want to do your own certification of a direct upgrade from your current Domino version prior to 6.5.x in your test environment and/or initially on the first production Domino Server by following the upgrade steps outlined in the "Deploying Domino Servers" page to upgrade to 8.5.x. Then, make your decision based on your results.
Here are the steps to upgrade a Domino version prior to 6.5.x to 6.5.x if you decide to go that route:
1. Make backup copies of all files, include transactional logs if appropriate.
2. Install the 6.5.6 FP3 server
3. Enable DEBUG_OUTFILE= in the notes.ini file to capture console output.
4. If time permits, run fixup against all databases, validating their integrity and repairing if necessary.
(n)fixup -f -j -v
Note:
-f Exhaustive fixup, all documents are checked.
-j Include transaction-logged databases if you have transaction logging enabled. Without this option, fixup does not repair logged databases.
-v Exclude database views (faster) Also, all views will be rebuilt later during the 8.5.x upgrade anyway.
You can use indirect files (.IND) to run multiple fixup processes concurrently to complete in a more timely manner.
For more information on how to create and run indirect files refer to the wiki article: Using indirect files to run maintenance tasks
Check the DEBUG_OUTFILE for any errors, possibly indicating data corruption. Query Knowledge Base and/or work with Lotus Support to get them resolved
5. If upgrading from a Domino version prior to 6.0, perform a copy-style compaction on all databases to bring the ODS level up to 43.
(n)compact -c
You can use indirect files (.IND) to run multiple compact processes concurrently to complete in a more timely manner.
Check DEBUG_OUTFILE for any errors possibly indicating data corruption. Query Knowledge Base and/or work with Lotus Support to get them resolved
6. If you decide to run the Domino Server at Release 6.5.x before upgrading to 8.5.x add the following steps, otherwise go directly to the upgrading to 8.5.x instructions
a) Run the updall process against all databases on the Domino Server
(n)updall
You can use indirect files (.IND) to run multiple updall processes concurrently to complete in a more timely manner.
b) Start the 6.5.x Domino Server
Now you are already to proceed with the instructions on upgrading directly to 8.5.x. Proceed to the next page, "Page 1b: Planning the Domino Server 8.5.x deployment, continued".
Back to top
Prepare your production environment before you upgrade
Before beginning the actual upgrade of your environment to Notes/Domino 8.5.x, preform these steps:
1. Normalize your environment. Resolve any major issues or crash/hang conditions before you upgrade with Lotus Support. Don't assume the upgrade will fix these issues, unless documented.
2. Investigate the compatibility of vender-supplied applications and companion products with Domino 8.5.x.
3. Make backup copies of all files, include transactional logs if appropriate.
4. Enable DEBUG_OUTFILE= in the notes.ini file to capture console output.
5. If time permits, run fixup against all database validating their integrity and repairing if necessary.
(n)fixup -f -j -v
Note:
-f Exhaustive fixup, all documents are checked.
-j Include transaction-logged databases if you have transaction logging enabled. Without this option, fixup does not repair logged databases.
-v Exclude database views (faster) Also, all views will be rebuilt later during the 8.5.x upgrade anyway.
You can use indirect files (.IND) to run multiple fixup processes concurrently to complete in a more timely manner. For more information on how to create and run indirect files refer to the wiki article: Using indirect files to run maintenance tasks
Check DEBUG_OUTFILE for any errors possibly indicating data corruption. Query Knowledge Base and/or work with Lotus Support to get them resolved
Note: If you don't have time to run FIXUP on all databases, at a minimum, run FIXUP on your system databases.
6. Verify all system databases have inheritance turned on
- NAMES.NSF (StdR4PublicAddressBook)
- LOG.NSF (StdNotesLog)
- EVENTS4.NSF (StdR4Events)
- ADMIN4.NSF (StdR4AdminRequests)
- DDM.NSF (StdDomainMonitor) - when upgrading from 8.0.x or greater to 8.5.x
This is so the Design Task can be utilized to refresh the system database designs with the Domino Server down
(If not, at a later time, you may need to manually replace the design of some system databases using Domino Admin Client)
Back to top
Plan your deployment sequence
This is the classic deployment sequence, but this does not account for organizational, demographic or other constraints. This should be used as a guiding principle while taking other factors of your business into account.
Items 1-3, highlighted in yellow, need to occur regardless of the overall strategy and sequence of server/client upgrades.
If you decide to upgrade the design of the Domino directory in your Domain in step 2 before upgrading any Domino Servers to 8.5.x, you will have to first get a copy of the Domino directory template (PUBNAMES.NTF). Install Domino 8.5.x on a test server and retrieve the template from there and copy to your admin client.
Important Note: The Domino Directory Design has been changed in Domino 8.5.1. Changes include View design updates in the following Views: People, PeopleCat, $PeopleGroupsFlat, $PeopleGroupsHier, Mail Users, PeopleCertExpiration. Please test any custom applications, agents, scripts, tools, automated processes, etc., that run against the Domino Directory and ensure they run successfully.
Another option is to upgrade the design of the directory when you upgrade the Admin Server of the Domino directory to 8.5.x when all other system database designs are upgraded as well.
Important Note: Some customers, especially enterprise customers with thousands of users in their Domino Directory, may want to control the flow of the new Domino directory design out into the domain. This will be discussed in the "Deploying Domino Servers" page.
Items 4-5, highlighted in red, can be achieved in various ways; all non-user facing servers upgraded before those that users access (as depicted here) or in larger organizations it may make more sense to upgrade all servers in a given location before moving to the next location in which case some infrastructure and some user accessed servers will be upgraded at the same time.
Most Domino upgrades are relatively straightforward and cause minimal disruption to your production environment. However, you are strongly encouraged to plan the order and pace of Hub and Mail Server upgrades. Planning these steps wisely can minimize risk of service problems, while still maintaining your upgrade schedule. When upgrading software, many enterprises follow the principle of stepwise upgrade. The basic idea is to at each step of the process, preserve the opportunity to back off to the previous step, until you are confident in the current step.
IBM recommends choosing a single, or small number of servers for the first step of the process. The server(s) should be chosen based on a tradeoff between being representative of your production environment but also involving less business risk, if possible. This allows you to ensure configuration and tuning of the upgraded environment is optimal for the broader deployment. Criteria for success should be set for this and each subsequent step. It is recommended that one of the criteria be delta change in key parameters you monitor routinely, but especially these parameters should include CPU, virtual memory usage, and storage operations (reads and writes). Compare CPU, virtual memory and storage operations for a period of several days before and after upgrade and investigate significant differences unaccounted for by component changes in the upgrade. Enterprises with passive (fail over) servers should consider deploying one of these as a first step to further reduce risk.
Subsequent steps should be small enough (for example involve the appropriate level of change, say the number of servers) to enable back out to the previous step, if necessary, at least in the earlier stages of a deployment. Again, providing an opportunity for additional optimizations for your specific environment. As more servers are upgraded, and confidence increases, enterprises usually increase the rate of change and size of particular steps.
IBM also recommends wise use of any failover architecture you may have implemented to reduce risk during upgrades. Some enterprises, for example, delay upgrading both pairs in two-way clusters until all of one side is upgraded. If a problem occurs with an upgraded server, failover to a clustermate is a possibility with high probability of success. Consider upgrade of the Active side of Active/Passive pairs first. This enables deployment on production loads, while preserving failover opportunity. Larger enterprises also do well to consider a production failover test to validate previous hardware sizing assumptions for clustermates. Failover test criteria should also include monitoring.
Items 6-9 are important steps to take advantage of all of the new features that Notes and Domino 8 have to offer. Given the large size of your Notes client base, communication needed, training required, etc. these steps are often carried out months after the server upgrades. This allows time for production testing before rolling out to hundreds or thousands of users.
Now you are ready to begin the upgrade process by following the steps on the Deploying Domino Servers page.
Back to top
How Customers and Business Partners download Notes/Domino 8.5.2
Back to top
For the latest news...
Fix List
For information and progress on issues fixed in the different releases, visit the Notes/Domino Fix List Database.
Support News and Flashes
Before beginning your upgrade, check the Product News page and the Flashes and alerts page on the IBM Support Portal for critical information and updates.
Back to top
Other helpful resources
In the following pages, you will be linked to many technical resources to help you during your upgrade process. Many of those links are specific to help you through a particular step or to help you avoid a known issue. Also visit our List of Lotus Notes and Domino 8.x upgrade resources page for more general resources.
Back to top
Table of Contents | Next
To provide feedback on this content, please send an email to ndinfo@us.ibm.com
|
|
|
|
| Version 51 |
November 21, 2011 |
4:29:57 PM |
by Terri Puckett  |
|
|