Moving the NSM 2.x for eDirectory Engine to another server
Last modified: 2010-Dec-22
Q: How do I move my NSM 2.x for eDirectory Engine server from one server to another?
A: If you need to move your NSM Engine to another server, follow the steps below:
Do not use this process to upgrade!!! Move first, then upgrade for best results.
Background: The Novell Storage Manager team has introduced version 2.5, and introduced a few changes in the naming of the NSM components, and added a couple of new components for OES2-Linux.
The Engine NLM has been renamed from FSFEngin.NLM in v2.0 to NSMEngin.nlm in v2.5, but will be referred to in this document as simply the Engine. The FSFEvent.nlm which housed the Event Monitor and Sentinel services has been split. The FSFEvent.nlm has been renamed to NSMEvent, and includes only the Event Monitor process, and will be referred to as the Event Monitor. The Sentinel service has been moved to its own NLM called NSMAgent.nlm, and will be referred to as the Agent. NSM v2.5 has also introduced OES2SP1 based Event Monitors and Agents.
Step 1
- Document which servers are running the Event Monitor and Sentinel/Agent services as this information will be needed later when re-deloying thse services to talk to the Engine in the new location.
- Using NSMAdmin remove all NetWare based Event Monitors and Sentinel/Agent services.
- Deregister all OES-Linux based Event Monitors and Agents. These services will have to have be updated via the nsmevent-config, and nsmagent-config utilities on their specific servers to point to the new location of the engine.
* * * Warning * * *
Please ask your administrators to hold off on object creates, moves, deletes, and renames, on managed objects, since all of the Event Monitors have been removed or deregistered.
Note: Backfills/Management Actions will have to be performed to get NSM to manage objects that changed while the Event Monitors are down.
Step 2
- Verify that there are no pending Eligible Events. (Best Practice)
- Unload the Engine from the current server, along with any other local NSM components if still running.
- Remove any NSM load commands in Autoexec.ncf file on the original server.
Step 3
- Run NSM Install program for the currently installed version of NSM on the new Engine server.
- Use the same proxy accounts that were used during the previous Engine installation. The installer will reset the passwords.
- Do NOT load the Engine when prompted during the install.
Step 4
- Copy the following directories from the old server's installation directory (SYS:\FACTORY by default) to the new server's FACTORY directory (Overwrite ALL existing files):
- DBASE
- LOGS
- STATS
- REPORTS
- SNAPSHOT (v2.0 Only)
- PROXYHOM (Optional) Especially if it has been modified from the original.
- WORKFLOW
- SENTINEL (v2.0 Only)
- AUDITLOG (Optional)
- Check www.storagemgr.com for any updates to NSM components in the same version family.
- Load the Engine on the new server
- NSM v2.5
SYS:Factory/NSMEngin.nlm
- NSM v2.0
SYS:Factory/FSFEngin.nlm
- NSM v2.5
Step 5
- Load NSMAdmin and re-deploy Event Monitors, and Sentinel/Agent servers
- Use the nsmevent-config and nsmagent-config utilities to update the Event and Agent configurations to point to the newly installed Engine address.
- Use NSMAdmin to re-register NSM Linux components.
Step 6
-
Rename the old server's FACTORY directory so that the old Engine cannot be accidently restarted on the old server without seeing that the directory has been renamed. We want it to be obvious that this directory is no longer in use. We recommend saving this directory for a day or two as a precaution. If everything runs correctly delete this old FACTORY directory.