home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Support Encyclopedia 96-1
/
novell-nsepro-1996-1-cd2.iso
/
download
/
netware
/
ngm192.exe
/
NGM192.TXT
next >
Wrap
Text File
|
1994-05-26
|
37KB
|
775 lines
NOVELL TECHNICAL INFORMATION DOCUMENT
TITLE: Global MHS 2.0b to 2.0c Upgrade
DOCUMENT ID: TID200052
DOCUMENT REVISION: A
DATE: 26MAY94
ALERT STATUS: Yellow
INFORMATION TYPE: Symptom Solution
README FOR: NGM192.EXE
NOVELL PRODUCT and VERSION:
NetWare Global MHS 2.0
ABSTRACT:
This patch is designed to upgrade NetWare Global MHS v2.0b to v2.0c. If you
have a version other than an official red box or patched version of NGM2.0b,
this upgrade will not work. This GMHS patch for NetWare 4.01 works in Bindery
Emulation mode ONLY. Please read this entire document before starting an
installation of GMHS on your NetWare 4.01 server.
──────────────────────────────────────────────────────────────────────────────
DISCLAIMER
THE ORIGIN OF THIS INFORMATION MAY BE INTERNAL OR EXTERNAL TO NOVELL. NOVELL
MAKES EVERY EFFORT WITHIN ITS MEANS TO VERIFY THIS INFORMATION. HOWEVER, THE
INFORMATION PROVIDED IN THIS DOCUMENT IS FOR YOUR INFORMATION ONLY. NOVELL
MAKES NO EXPLICIT OR IMPLIED CLAIMS TO THE VALIDITY OF THIS INFORMATION.
──────────────────────────────────────────────────────────────────────────────
SYMPTOM
Users want to upgrade NetWare Global MHS v2.0b to v2.0c for NetWare 4.01
support in Bindery Emulation mode.
SOLUTION
Apply NGM192.EXE.
Self-Extracting File Name: NGM192.EXE Revision: A
Files Included Size Date Time
\
NGM192.TXT (This File)
PATCH.EXE 78129 01-19-93 12:18a
README.UPG 34547 05-25-94 12:21p
PATCHNGM.BAT 2331 05-26-94 10:22a
UPGRD20C.RTP 201719 05-25-94 4:59p
Installation Instructions:
Make sure that the Btrieve page size is set to 4096 when Btrieve is
loaded:
load btrieve -p=4096
REQUIRED SOFTWARE
**NOTE** This patch is designed to upgrade NetWare Global MHS v2.0b to
v2.0c. If you have a version other than an official red box or patched
version of NGM2.0b, this upgrade will not work.
To determine your current NGM version, type 'load MODULES' at the server
console prompt and verify that the version number for 'NGMADMIN.NLM' is
v2.0b.
If you have any other version, contact your local Novell representative
to receive the appropriate upgrade for your system.
For information on installing NetWare Global MHS, refer to your
"Installing NetWare Global Messaging" manual, part number 100-001200-001.
This patch version must be loaded ONLY on NetWare 4.01 (not 4.0), and you
must use the CLIB and Btrieve specified in this document.
_____________________________________________
PROCEDURE FOR INSTALLING GMHS ON NETWARE 4.01
Step 1: Verify that the following NetWare 4.01 configuration parameters
are set as indicated. GMHS requires these parameters for proper
installation and operation.
a. Allow Invalid Pointers = ON
b. Read Fault Emulation = ON
c. Write Fault Emulation = ON
You can verify this by:
1. Loading SERVMAN.NLM on the system console
2. Selecting 'Console Set Commands'
3. Selecting 'Memory' option
If the above three parameters are not set to ON, please change
them. All three parameters should be turned ON.
Step 2: Establish the Bindery Emulation Context for all users on that
NetWare 4.01 server. This is done using NDS administration
utilities.
Step 3: Add the group EVERYONE to the NDS Container associated with the
above Bindery Emulation Context.
Step 4: If this context has a user called "Admin" then please rename
this user to avoid conflicts with GMHS's Admin user that is
normally associated with the "Supervisor" Bindery user.
Alternatively, make sure that the GMHS postmaster user is not
'ADMIN' (can be ADMIN1 for instance) in step 6.
Step 5: Load the following versions of CLIB.NLM and BTRIEVE.NLM:
CLIB.NLM version 4.01D dated February 24, 1994.
BTRIEVE.NLM version 6.10C dated November 19, 1993.
Step 6: Install GMHS from the media in the GMHS red box following GMHS
installation guidelines. If you need to change the name of the
postmaster user from ADMIN to something else do so at this
stage.
Step 7: If you use the NGMStart.ncf file to run NGM you must edit
NGMStart.ncf to have it load the correct versions of CLIB and
Btrieve, specifying the directories where these new files were
copied to in step 5. Do NOT use CLIB and Btrieve installed in
the NGM\BIN directory by the GMHS install program.
Step 8: Execute the GMHS patch copied down from NetWire.
(See 'UPGRADING YOUR SERVER', below, for instructions on the
patch upgrade procedure)
Step 9: Load NGM following the instructions on running NGM.
*NOTE1* The following message may be displayed on the server
console during the installation of GMHS v2.0c on a NetWare
4.01 server:
"Read from a non-present page
Process: Pinstall.nlm 0
Module: NetWare Server Operating System
Code offset in module: FD006A3FH
Access address: 0000008EH"
This message should not be considered a problem and is to
be expected for an initial installation of GMHS v2.0c on
NetWare 4.01.
*NOTE2* When this patched NGM.NLM software is loaded, you will see
the following warning message.
"This module uses 4 outdated API calls you should
upgrade to a newer module when it becomes available"
This message is for informational purposes only. This
version of NGM has been upgraded for NetWare 4. You should
ignore this warning message.
*NOTE3* There can be a NetWare problem when several multi-NLM
products are loaded from AUTOEXEC.NCF. The primary
symptom is the server may reboot itself while in the
process of loading an NLM of a multi-NLM product.
This reboot may repeat several times before the server
manages to successfully come up with all products loaded.
If you experience this symptom and your AUTOEXEC.NCF is
loading multi-NLM products, remove the LOAD commands for
those multi-NLM products from AUTOEXEC. Load those NLMs
manually after your server has completed its boot
procedure.
_____________________________________________
UPGRADING YOUR SERVER
Step 1. Login to your NGM server as supervisor.
Step 2. Verify that your server has at least 8.0 MB of free hard disk
space. This is the recommended minimum required to perform this
upgrade.
Step 3. The contents of the NetWare Global MHS 2.0C for NetWare 4.01
patch is as follows:
a. README.UPG
b. PATCH.EXE
c. PATCHNGM.BAT
d. UPGRD20C.RTP
Step 4. Copy the files 'PATCH.EXE', 'PATCHNGM.BAT', and 'UPGRD20P.RTP'
to the root NGM directory. The default NetWare Global MHS
directory is <Server\Volume:\NGM\>.
Sample:
COPY PATCH.EXE <volume>:\NGM\PATCH.EXE
COPY PATCHNGM.BAT <volume>:\NGM\PATCHNGM.BAT
COPY UPGRD20C.RTP <volume>:\NGM\UPGRD20C.RTP
If you installed NetWare Global MHS in some other directory, be
sure to copy the upgrade files to that directory.
For example, if NetWare Global MHS is installed in the
directory <Server\Volume:\PUBLIC\MAIL\NGM\>, enter the
following:
Sample:
COPY PATCH.EXE <volume>:\PUBLIC\MAIL\NGM\PATCH.EXE
COPY PATCHNGM.BAT <volume>:\PUBLIC\MAIL\NGM\PATCHNGM.BAT
COPY UPGRD20C.RTP <volume>:\PUBLIC\MAIL\NGM\UPGRD20C.RTP
The patch program searches down through all subdirectories to
find the appropriate files to upgrade. Therefore, it is very
important to start the upgrade procedure from the correct
directory.
Step 5. Unload NGM at the server console and make a backup copy of your
NetWare Global MHS Directory structure.
IMPORTANT: Do not save backup files under the same directory
structure in that you installed NetWare Global MHS. The
upgrade procedure will update the first file within the
directory structure. If this first file happens to be a
backup file, then the correct system file may not be
upgraded.
Step 6. Change to the root NGM directory (where you copied the upgrade
files). Enter:
PATCHNGM
The patch program upgrades all appropriate files. The patch
program also retains a log of the results in a file called
'RESULTS.TXT'. To verify your upgrade installation, view the
contents of 'RESULTS.TXT' after the upgrade is complete.
Step 7. During the patch process a BACKUP directory is created under
the directory from that you ran 'PATCHNGM'. The BACKUP
directory contains all files that were changed and a file
called 'UNPATCH.BAK'. After the patch process has completed do
NOT delete the BACKUP directory until you are satisfied that
the upgrade procedure was successful. If you want to undo your
upgrade and return your installation to its previous state,
perform the following procedure.
■ To restore your system, change to the BACKUP directory, copy
'UNPATCH.BAK' to `'UNPATCH.BAT', and type "UNPATCH". This
file will delete all new files in the appropriate directories
and replace them with the files that originally existed.
■ Verify the original files have been correctly reinstalled.
■ In order to rerun the patch process, or add additional patches,
you MUST delete or rename the BACKUP directory first.
Otherwise, the patch procedure will be unable to create an
accurate BACKUP of the changes being made during the subsequent
upgrade.
Patch History:
_____________________________________________
UNRESOLVED ISSUES
This document will be updated pending verification of the following
issues:
1. Compatibility with SNADS for NetWare Global MHS.
2. Compatibility with SMTP for NetWare Global MHS.
3. Compatibility with Retix X.400 for NetWare Global MHS.
Solution Specifics:
This upgrade changes the following files.
1. NGM.NLM
2. NGMSMF.NLM
3. NGMAMP.NLM
4. NGMADMIN.NLM
5. NGMINS.NLM
6. NGMEXTRC.NLM
7. NGMDEINS.NLM
8. NGMUPGDE.NLM
9. NGMDSYNC.NLM
This upgrade does not change the serial number and maximum number of
licensed users for your NetWare Global MHS installation.
This upgrade provides the following changes:
1. Illegal Memory Access:
■ NGMINS and NGMDEINS were passing a memory block without calling
InitScratchMemory.
■ NGMEXTRC was trying to initialize an invalid handle that is no
longer used.
■ NGMUPGRADE was passing an absolute pointer to create screen.
This pointer is not valid in theupgraded NUT.NLM.
■ NGMADMIN was allocating memory using malloc and was trying to
deallocate it using FREE() instead of free().
■ NGMADMIN abended when deleting a gateway host. This problem was
resolved by checking the pointer to the gateway host name
before deleting it.
■ NGMSMF abended when adding a new application. Problem resolved
by passing the correct pointer to application record.
2. Unreleased Resources:
■ When any module is loaded with -s option CreateScreen allocates
memory. This memory was not released when the module was
unloaded. Modified the modules DSYNC.NLM, NGM.NLM,
NGMEXTRC.NLM, NGMSMF.NLM to use DestroyScreen() to release the
memory.
3. Misbehaviors:
■ CMP now checks, during updates, that a deletion record's master
host and the original record'smaster host are the same.
■ Deleting a record did not generate opcode (Delete) in an ASCII
CMP message. Check is made against PL_DESTROY instead of
PL_DELETE.
_____________________________________________
RELEASE NOTES
________________________________________________
INSTRUCTIONS FOR INSTALLING GMHS ON NETWARE 4.01
Please read this entire document before starting an installation of GMHS
on your NetWare 4.01 server.
This GMHS patch for NW 4.01 works in Bindery Emulation mode ONLY.
The following installation procedures MUST be followed to successfully
install and configure GMHS on a NetWare 4.01 server.
This patch version must be loaded ONLY on NetWare 4.01 (not 4.0) and you
must use the CLIB and Btrieve specified in this document.
Installing and configuring GMHS on a NetWare 4.01 server requires the
following:
1. GMHS 2.0b software for NetWare 3.1x (Redbox or patch release)
2. GMHS 2.0c patch for NetWare 4.01 (Located on NetWire)
3. Proper versions of CLIB and BTRIEVE (Located on NetWire)
*NOTE* The following files can be found on NetWire in the following
locations:
BTRIEVE - NOVLIB Library 7 BTR61.EXE
BTRIEVE.NLM version 6.10C dated November 19, 1993.
(DO NOT use the CLIB version which is included in this self-extracting
archive)
CLIB - NOVLIB Library 4 LIBUP2.EXE
CLIB.NLM version 4.01D dated February 24, 1994.
Please make sure you have the installation media, the patch software, and
proper CLIB and Btrieve software, before proceeding with the installation
and configuration of GMHS on your NetWare 4.01 server.
**NOTE** To allow users to begin taking advantage of Global MHS on
NetWare 4.01 servers at the earliest opportunity, Novell has chosen to
release this with the following known issues. Some of these items have
gone through preliminary testing and appear to work; however, these do
require further testing and documentation before being supported. As
such, we will be confirming these issues over the following days and will
post an updated version of this release note that documents the support
status and procedures. This new posting will be an update only and the
patch will remain static.
If you are currently using a NetWare 4.01 server as a PASSIVE NetWare MHS
host and are upgrading that system to be an ACTIVE NetWare MHS host with
this release, the procedure for doing this will be available in the
updated release note.
Preliminary testing of this patch on NetWare 3 Global MHS servers has
been done in Novell's labs. However, there may be some issues relating
to certain versions of CLIB. We will be researching these dependencies
and will document them in the updated release note. Until then, applying
this patch to existing NetWare 3 Global MHS servers will be unsupported.
______________________________________
USER ADMINISTRATION/ACCOUNT MANAGEMENT
This section describes the guidelines for setting up and managing MHS
mailbox accounts given the interaction between NDS and the Global MHS
directory through the bindery emulation. This section assumes the reader
is familiar with and understands bindery emulation and NDS.
For a successful installation, it is very important to take the time to
understand this section and understand the operation of your MHS
application.
______________________________________
APPLICATION ISSUE
Most MHS applications have been developed with NetWare 3.x in mind. This
means the applications may make certain assumptions about bindery use,
traditional NetWare 3.x directory structures and so forth. In
determining how you will administer and manage the system, you must take
into account how the application is affected by your system
configuration. The following lists some of the known issues that you
should understand before starting. Please consult your MHS application
provider's documentation or technical support group to confirm these
items before you start.
1. Some applications make use of the SYS:\MAIL\<userid> directory
structure that was part of the NetWare 3.x system. NetWare 4.01
does not behave the same in this regard in that it does not provide
users access to their SYS:\MAIL\<userid> directory by default.
For example, Novell's own FirstMail mail application uses the
SYS:\MAIL\<userid> directory as its default message store. If you
upgrade your system from NetWare 3.x to NetWare 4.01, your rights
are likely preserved. If you have done a fresh installation of
NetWare 4.01, you must ensure that rights are properly assigned.
2. MHS applications vary some in how they locate the \MHS directory
tree. Most applications use the MV environment variable (see Global
MHS documentation for details). If your application uses the MV
variable you must ensure this variable is properly set in your
users' login scripts. If other methods are used, you must
understand how the application is affected by the administration
interactions described below.
3. Some MHS applications use environment variables to determine what
their MHS mail address is while others use techniques that involve
bindery calls. If your application uses an environment variable,
then you only need to make sure it is properly set as part of the
login script. If bindery calls are used, then you MUST carefully
follow the procedure recommended below and MUST NOT use the
'Advanced Configuration' method because applications will be unable
to determine their mail addresses in that case.
______________________________________
OVERVIEW OF NDS/GLOBAL MHS INTERACTION
Global MHS uses bindery emulation to associate user accounts with
physical mailboxes. A mailbox account is created by either importing
users from the bindery or by adding users through NGMADMIN. When using
NGMADMIN to add a user, the utility confirms the existence of the user's
account in the bindery. If there is no bindery user for the account being
created, a new bindery entry is added for the new mailbox account.
When using bindery emulation in NetWare 4.01, this Global MHS interaction
with the bindery indirectly introduces some dynamics with NDS. For
instance, if NGMADMIN is used to create an account for which no BINDERY
entry exists, a new bindery entry is created in the bindery context for
that server. This causes an NDS user object to be created at the same
time in the container object associated with the bindery context.
Conversely, when NWADMIN is used to add an NDS user object, a bindery
entry is created for that user on every server that uses that bindery
context.
These two indirect interactions impose some constraints about managing
Global MHS mailbox accounts. Understanding the interaction model is very
important to ensure a successful deployment. To avoid complex manual
administrative intervention, there are five recommended general
guidelines that will help you. These are summarized in the following
bullet points and will be explained in the following subsections. By
following these guidelines, the major features of Global MHS will work
successfully (such as, bindery import, sender validation, passive server,
and so forth). A more complex manual process can be achieved but is not
recommended because it adversely affects some of the Global MHS features.
■ Each NetWare 4.01 server that acts as an ACTIVE or PASSIVE Global
MHS server should use a bindery context that is unique for the
entire network.
■ All NDS user accounts that are to have mailbox accounts on a common
Global MHS server should be in the bindery context that is unique to
that server.
■ The Global MHS long names in the Global MHS directory are
independent of the NDS names and a consistently applied naming
scheme should be employed for the Global MHS names.
■ Global MHS mailbox deletion and NDS user object deletion are
independent events. If you delete a mailbox for a user, the NDS
account and bindery object remain intact. If you delete an NDS user
object, the mailbox remains intact (if one was created). You must
remember to delete accounts accordingly.
■ Use consistent methods for adding, deleting, and moving users to
avoid missing steps that might cause conflicts in name or account
locations. This is important because there are multiple ways to add
users to the system and depending upon the method used, other
procedures must follow.
If you follow these guidelines, existing bindery dependent applications
and all Global MHS features should work without any problem. However,
you must confirm application compatibility with your application
provider.
______________________________________
UNIQUE BINDERY CONTEXTS
If more than one server shares a common bindery context, the binderies
for those servers will be identical. That is, user accounts in that
context will receive bindery accounts on each of the servers. If bindery
import is used to create Global MHS mailboxes and multiple Global MHS
servers share the same context, then each user in that context will end
up with multiple mailboxes (one on each Global MHS server sharing the
same context).
When Global MHS synchronizes routes, conflicts can occur. This conflict
will also exist for a single Global MHS server that is the ACTIVE router
for a PASSIVE Global MHS system.
-----------------------------------------
MAILBOX USERS IN THE SAME BINDERY CONTEXT
When using bindery import in Global MHS, only NDS user objects in the
bindery context for that server will have bindery accounts that can be
imported. NDS user objects in different bindery contexts will be
invisible to Global MHS and therefore can not be imported. Therefore, if
you want a user's mailbox to reside on a particular Global MHS server,
that user's NDS account must exist in the bindery context for the target
Global MHS server.
If you have an existing NDS structure where users from multiple contexts
must have mailbox accounts on the same Global MHS server, you must alter
the NDS structure. One way to do this is to move all of the desired
users into the same bindery context as the Global MHS server and then
create NDS alias objects in the contexts where the user account
originally was located. This will allow the users to continue to log in
under their old NDS name (now an alias) while meeting the requirements
for Global MHS to operate.
***WARNING***
If a user is in the wrong context and you create an alias in the right
context, the desired affect will NOT be achieved!
For a bindery account to be visible to Global MHS, ensure the actual
non-aliased NDS object is in the Global MHS server's context.
If you choose to create Global MHS accounts using NGMADMIN, bindery
accounts will be created if the user does not exist in that context.
This will create an NDS account for that user in the bindery context of
that Global MHS server. You will likely want to then use NWADMIN to
complete configuration of that user account.
-----------------------------------------
NDS/GLOBAL MHS DIRECTORY STRATEGIES
Global MHS maintains a directory of mailbox names. These logical names
are hierarchical location independent names in the same way that NDS
names are hierarchical and location independent. Because Global MHS is
running in bindery emulation mode, the Global MHS directory names are
totally independent of the NDS names.
For example, the user Susan Jacobs might have an NDS name of Susan
Jacobs.Marketing.San Francisco.Acme and a Global MHS name of Susan Jacobs
@ Marketing.Acme. When logging into the network, the NDS name is
specified, but Global MHS knows Susan by the Global MHS name only.
To avoid confusion, a consistent naming strategy should be employed.
There are two recommended strategies. One strategy is to intentionally
make the Global MHS tree and the NDS tree naming conventions unique. The
second strategy is to make the Global MHS and NDS tree naming conventions
identical. There are pros and cons to each of these and each
administrator should decide that strategy is best. Either strategy will
be compatible with the upgrade for the forthcoming NetWare 4.x NDS
integrated MHS solution.
Unique naming conventions can be advantageous when people have selected
NDS conventions that are excessively long or suggest physical locations
or administrative partitions.
For example, if you use naming conventions like David Peterson.Segment
6.Building 3.Phoenix.Davis Corp, you will likely not want the user's NDS
name to be the mail name. Rather, you may find David Peterson@Davis Corp
to be more appealing for mail purposes.
Taking advantage of the independence between Global MHS and NDS naming
allows you to construct flat, concise mail directories while maintaining
deeper, more descriptive NDS naming (for network administration
purposes). The disadvantage of this scheme is that users will be known
by two logical names and there is no directly apparent correlation
between the NDS name and the Global MHS name (visible via NDS or Global
MHS tools). This correlation can only be determined by finding the NDS
and Global MHS names that are associated with the same bindery account.
Identical naming conventions can be advantageous if you want users to
only be known by one logical name. For instance, if you want the NDS
account Karen Woodward.Engineering.Software Gurus to be known as Karen
Woodward @ Engineering.Software Gurus in Global MHS, then identical
naming strategies are appropriate. However, if the NDS names you have
are long complex names that are non-intuitive, then identical naming may
not work well for you.
*REMEMBER* The long name used in Global MHS is independent of the NDS
name. If your Global MHS directory tree matches your NDS tree (by
manually creating it this way), users will only be created in the default
bindery context even if the Global MHS name is a different bindery
context!! If you are using aliases to allow people to log into different
contexts but use a common server for mail, you must manually create the
NDS alias for the user object created in the server's bindery context.
For example, you decide to create Jim Grubb @ Engineering.ABC by using
NGMADMIN but the default context for the server is Operations.ABC.
NGMADMIN will create a bindery account for Jim Grubb that results in an
NDS user object Jim Grubb.Operations.ABC. To keep the naming consistent,
you must remember to then use NWADMIN to manually create the alias Jim
Grubb.Engineering.ABC and associate it with the Jim Grubb.Operations.ABC
user object.
Conversely, suppose you want to create users through NWADMIN. If you
decide you want Jim Grubb to have a mailbox on the server in the
Operations.ABC context and also be listed in the Engineering.ABC context,
you must first create the Jim Grubb.Operations.ABC user object using
NWADMIN. You then create an alias for Jim Grubb.Engineering.ABC that
points to Jim Grubb.Operations.ABC. Finally, if you use NGMADMIN to add
Jim Grubb you must remember to manually set the long name to be Jim Grubb
@ Engineering.ABC.
-----------------------------------------
ACCOUNT DELETION
Global MHS will not delete bindery accounts if the mailbox is deleted
through NGMADMIN. Generally, this is a desired behavior. Conversely, if
you delete an NDS user object that has a corresponding Global MHS
account, the mailbox is not deleted. This may not be the desired
behavior since there is no longer a user associated with the account.
You must remember to delete the Global MHS account separately from NDS
user object deletion.
-----------------------------------------
CONSISTENT ADMINISTRATION
The key to success is to employ a consistent administrative process for
adding, moving or deleting users. This will ensure that you don't miss
steps or introduce inconsistency in your naming strategies.
For example, you might decide to always add users by first adding them
via NWADMIN and then adding them through Global MHS bindery import (or
NGMADMIN).
Conversely, you might decide to first create the mailbox account via
NGMADMIN and then use NWADMIN to complete account setup. The following
are two sample procedures you could adopt.
User Add Procedure from NDS:
1. Add the NDS user object in the bindery context for the Global MHS
server where the mailbox should reside.
2. Create any needed alias for the NDS user object in different
context(s) if desired.
3. Use NGMADMIN to add the mailbox and set the MHS long name according
to convention used.
Delete User Procedure from NDS:
1. Note the MHS long name for the user to be deleted.
2. Delete the NDS user alias (if it exists).
3. Delete the NDS user object.
4. Use NGMADMIN to delete the MHS account (noted from step 1).
User Add Procedure from Global MHS:
1. Use NGMADMIN to add the MHS user and set the long name according to
desired convention.
2. Use NWADMIN to edit the NDS user object in the context for the
Global MHS server.
3. Use NWADMIN to create any alias for the NDS user object (if
necessary).
User Delete Procedure from Global MHS:
1. Note the NDS account associated with the mailbox to be deleted.
2. Use NGMADMIN to delete the MHS account.
*NOTE* If you do not want to delete the user object, stop at this point.
3. Use NWADMIN to delete any alias associated with the NDS account
noted in step 1.
4. Use NWADMIN to delete the NDS user object noted in step 1.
-----------------------------------------
ADVANCED CONFIGURATION
If you are willing to give up bindery import from Global MHS, you do not
want to use sender validation, you will not be using passive servers, and
you are unwilling to have the restriction of all unique bindery contexts
for each Global MHS server with all MHS users in the same context for
that Global MHS server, you can do so.
This is not recommended because you must understand mailbox access rights
controls in addition to fully understanding the interaction issues of NDS
(introducing room for manual error). For those requiring this
capability, this section describes the procedure.
APPLICATION INCOMPATIBILITY WARNING:
If you use the following procedure, bindery accounts will not be
available for users in different contexts than the default context of the
Global MHS server. Applications that use bindery information will not
work for those users in other contexts. Refer to the earlier section on
Application Issues before proceeding with this configuration.
OPERATIONAL WARNING:
If you use this process, you must not use bindery import from Global MHS.
Doing so will cause a number of problems. To reinstate bindery import
compatibility, you must completely restructure your NDS tree according to
the constraints listed under the recommended procedure.
Secondly, because Global MHS uses bindery file ownership for sender
validation, sender validation will not work.
Third, any errors in setting up user rights in the MHS directory
structure may render your Global MHS system inoperable.
Again, Novell strongly recommends that you use the procedures listed
earlier. This information is only being provided as a matter of
convenience for highly skilled and advanced MHS users who are willing to
accept responsibility for proper and full manual administration.
User Add from NDS:
1. Add the NDS user object from NWADMIN in any desired context.
2. Use NGMADMIN to add a mailbox account and set the long name
according to your desired convention.
3. Assuming the NDS user object is not in the bindery context for the
Global MHS server, use NWADMIN to delete the user object that was
created when NGMADMIN added the bindery account for the new mailbox
account.
4. Use NWADMIN to grant the NDS user object (created in step 1) proper
rights to the MHS mailbox directory created by NGMADMIN.
(\MHS\MAIL\USERS\<gmhs short name>).
5. Use NWADMIN to grand the NDS user object (created in step 2) proper
rights to the \MHS\MAIL\SND, \MHS\MAIL\PARCEL, and \MHS trees.
*NOTE* Refer to Global MHS documentation to learn that rights are set in
the \MHS directory structure.
User Add from Global MHS:
1. Use NGMADMIN to add a mailbox account and set the long name
according to your desired convention.
2. Add the NDS user object from NWADMIN in any desired context.
3. Assuming the NDS user object is not in the bindery context for the
Global MHS server, use NWADMIN to delete the user object that was
created when NGMADMIN added the bindery account for the new mailbox
account.
4. User NWADMIN to grant the NDS user object (created in step 1) proper
rights to the MHS mailbox directory created by NGMADMIN
(\MHS\MAIL\USERS\<gmhs short name>).
5. Use NWADMIN to grand the NDS user object (created in step 2) proper
rights to the \MHS\MAIL\SND, \MHS\MAIL\PARCEL, and \MHS trees.
*NOTE* Refer to Global MHS documentation to learn that rights are
assigned in the \MHS directory structure.
────────────────────────────────────────────────────────────────
Any trademarks referenced in this document are the property of their
respective owners. Consult your product manuals for complete trademark
information.
────────────────────────────────────────────────────────────────