home *** CD-ROM | disk | FTP | other *** search
/ Network Support Encyclopedia 96-1 / novell-nsepro-1996-1-cd2.iso / download / netware / 4xrep1.exe / UPGRADE.DOC < prev   
Text File  |  1995-11-17  |  25KB  |  638 lines
  1. UPGRADE.TXT
  2. ________________________________________________________________
  3. This readme is for installations migrating from NetWare versions
  4. prior to 4.1, especially when a mixed 4.0x/4.1 environment might
  5. be maintained for a period of time.  If all servers have been 
  6. upgraded to NetWare 4.1 this information is unnecessary.
  7.  
  8.  
  9. This readme contains the following sections:
  10.  
  11. I.   Summary
  12. II.  General Upgrade Hints
  13. III. Run DSREPAIR Before You Upgrade 
  14. IV.  Strategy for Migration 
  15. V.   Installing the New DS.NLM on Existing NetWare 4.1 Servers
  16. VI.  Running a Mixed Environment for an Extended Time
  17. VII. Supplement to "Introduction to NetWare Directory Services"
  18.  
  19.  
  20. I. SUMMARY
  21.  
  22. Part of the upgrade procedure is a check to be sure that
  23. there are no data inconsistencies in the current Directory
  24. Services data.  
  25.  
  26. Although Novell recommends that customers upgrade all
  27. servers to NetWare 4.1, a mixed environment will function
  28. properly if you use this procedure.  To ensure that your
  29. upgrade is smooth, Novell recommends the following: 
  30.  
  31.  
  32. - Run the DSREPAIR utility (version 2.23e) on each NetWare
  33.   4.0x server before you upgrade the server.  Note the
  34.   instructions in section III of this readme.  This file is
  35.   supplied as REPAIR.NLM.
  36.  
  37. - Upgrade all versions of NetWare 4.0x to NetWare 4.1 as
  38.   soon as it is practical.
  39.  
  40. - Install DS.NLM version 4.89  onto all NetWare 4.1 servers. 
  41.   This version of NDS is more tolerant of data inconsistencies
  42.   in previous NetWare 4.0x NDS databases, and will provide
  43.   better mixed environment interoperability.
  44.  
  45. - Whenever possible, upgrade all servers in a partition at
  46.   the same time.
  47.  
  48.   (When you upgrade NetWare 3.x servers, add them to
  49.   partitions where all other servers have been upgraded to
  50.   NetWare 4.1.)
  51.  
  52. If you must maintain NetWare 4.0x servers, or if you must
  53. upgrade gradually, Novell recommends the strategy outlined
  54. in this readme.
  55.  
  56. NetWare 4.1 has a more accurate means of tracking objects,
  57. containers, and other items in the NetWare Directory
  58. Services (NDS) tree using the time-and-date stamp. 
  59.  
  60. Because the time-and-date stamps on NetWare 4.0x servers
  61. might have been altered, there can be inconsistencies in the 
  62. NetWare 4.0x data which may impact upgrades.
  63.  
  64. The DSREPAIR part of the process will correct or identify
  65. data problems which could impede the upgrade process.  Even
  66. if you are not ready to upgrade, you can use this DSREPAIR
  67. to correct data defects in the Directory Services database.
  68.  
  69.  
  70. II. GENERAL UPGRADE HINTS
  71.  
  72. During your upgrade process you will be running in a mixed
  73. 4.0x/4.1 environment.  Until all servers in the NDS tree are
  74. running NetWare 4.1, you won't fully realize the benefits of
  75. increased speed or reliability, nor can you use all 4.1
  76. features.
  77.  
  78. The following hints will help you with the upgrade process: 
  79.  
  80. - Read the errata that is found in the NetWare 4.1 box.
  81.  
  82. - Read and follow the README.41 file.
  83.  
  84. Install lets you read this document, but you should review
  85. it BEFORE you actually begin the installation.  This ASCII
  86. text file is found in the \NW410\INSTALL\ENGLISH\README
  87. directory on the 4.1 CDROM and can be copied from the CDROM
  88. or read directly.
  89.  
  90. The README.41 file covers important limitations of having a
  91. mixed 4.0x/4.1 tree. The most important parts of that
  92. document are included at the end of this readme as 
  93. "VII. Supplement to "Introduction to NetWare Directory
  94.  Services."
  95.  
  96.  
  97.  
  98. III. RUN DSREPAIR BEFORE YOU UPGRADE
  99.  
  100.      A. POSSIBLE INCONSISTENCIES IN OLD TREE DATA
  101.  
  102.      NetWare 4.1 has many improvements to ensure reliable,
  103.      stable use of Directory Services.  Much work was done
  104.      to ensure that the data contained in older versions of
  105.      NetWare Directory Services would migrate easily to the
  106.      current release.  To optimize NetWare 4.1 NDS performance,
  107.      check for possible NDS database inconsistencies before
  108.      upgrading.  
  109.  
  110.      The version of DSREPAIR included in this package has
  111.      features which make it a useful tool to check a NetWare
  112.      4.0x NDS database before upgrading to NetWare 4.1. The
  113.      DSREPAIR.NLM is named REPAIR.NLM in this package.
  114.  
  115.      Because running DSREPAIR before upgrading ensures that
  116.      NetWare 4.1 will perform as designed, run DSREPAIR version
  117.      2.23e on EACH 4.0x server before you upgrade that server. 
  118.      This DSREPAIR will run only on NetWare 4.0x servers and is
  119.      not intended for NetWare 4.1 servers.
  120.  
  121.      Although this DSREPAIR will correct most NDS Database
  122.      inconsistencies, there may be a few conditions where you
  123.      will need to contact Novell. Those conditions are indicated
  124.      in the special DSREPAIR instructions below and are indicated
  125.      by the code [PBD]. Contact Novell to resolve these
  126.      problems before upgrading.  
  127.  
  128.      You should contact Novell through your standard support
  129.      channel, such as your reseller, distributor or consultant.
  130.  
  131.  
  132.      B.  RUNNING DSREPAIR
  133.  
  134.      The document, REPAIR.DOC, has the general operating
  135.      instructions for this version of DSREPAIR.
  136.      The following are specific instructions and a summary of
  137.      some of the features in this version of DSREPAIR that have
  138.      proven useful to some of our upgrading customers.  This
  139.      version of DSREPAIR will allow the user to more quickly
  140.      resolve possible issues and upgrade easily.  
  141.  
  142.      To use this DSREPAIR, copy it to SYS:SYSTEM on the NetWare
  143.      4.0x server or run it from a diskette.  By running the
  144.      various options, and appending to the LOGFILE, you will
  145.      obtain a record in the file SYS:\SYSTEM\DSREPAIR.LOG that
  146.      can be viewed in an editor or printed.
  147.  
  148.     DSREPAIR will correct many errors automatically, but you
  149.     must manually correct some errors before upgrading.  After
  150.     correcting the errors, re-run DSREPAIR to make sure you have
  151.     not missed any.
  152.  
  153.  
  154.     - Communication errors:
  155.  
  156.       All servers must be properly synchronized before you can
  157.       perform an upgrade.  If a server is down, or is not
  158.       communicating properly, this condition will be reported in
  159.       the error log.  
  160.  
  161.       You must resolve the communication link or bring the
  162.       server up and allow synchronization to complete.  If the
  163.       server has been removed from the network but still exists
  164.       within the Directory Services database, follow the
  165.       instructions in the DSREPAIR.DOC.  You won't complete a
  166.       smooth upgrade if you are experiencing communications
  167.       problems.
  168.  
  169.  
  170.       - Same name Siblings:  
  171.  
  172.         With NetWare 4.0x, objects with duplicate names but of
  173.         different types were allowed.  For example, in NetWare
  174.         4.0x a container and a user could have the same name.
  175.         This is not permitted in NetWare 4.1 (to simplify use
  176.         and prepare for future applications).
  177.  
  178.         Before you upgrade, rename (or delete) the leaf object
  179.         (user in this example).  This version of DSREPAIR
  180.         locates and report siblings of the same name for you.
  181.         If you see an entry indicating a duplicate name, as in
  182.         
  183.         Duplicate or ambiguous name: [objectname] 
  184.  
  185.         go to NWADMIN (or NETADMIN) and rename one of the
  186.         objects.
  187.  
  188.       - Duplicate Time Stamps:  
  189.  
  190.         No two objects should have the same time stamp.
  191.         Previous problems with your time synchronization 
  192.         could have caused incorrect time stamps. This 
  193.         condition results in a [PBD] timestamp entry in the
  194.         error log.
  195.  
  196.         If you receive a [PBD] Timestamp in the error log,
  197.         you must delete one of the objects. Following, allow
  198.         time for synchronization and then rerun DSREPAIR to 
  199.         verify that no duplicate timestamps exist.
  200.  
  201.         If both objects are container objects, and both have a
  202.         significant number of leaf objects below them, deleting
  203.         and recreating one of the objects manually could be very
  204.         time consuming.
  205.  
  206.        WARNING: If the LOGFILE contains any messages with the
  207.        prefix [PBD], as in [PBD] Duplicate creation time stamps
  208.        DO NOT UPGRADE the server. Contact Novell to assist in
  209.        resolving the problem before upgrading. You may continue
  210.        to operate the server as a NetWare 4.0x server until this
  211.        data is corrected.
  212.  
  213.     
  214.      - Backlinks and External references:  
  215.  
  216.        External references are pointers used when object
  217.        information must be maintained where the object itself
  218.        does not exist.
  219.  
  220.        For example, an external reference would be used when
  221.        a user has rights to a file on a server that does not
  222.        contain a replica of the partition where the user object
  223.        is located. Directory Services maintains these pointers
  224.        and they must be properly back linked (associated with
  225.        real object) before you upgrade.  
  226.  
  227.        To verify that the external references are correct, from
  228.        the main DSREPAIR menu choose option "8".  External
  229.        references that might not properly match the real 
  230.        object will be corrected.  If improper external
  231.        references are found and cannot be corrected they
  232.        will be identified in the LOGFILE.
  233.  
  234.        If the LOGFILE contains any messages with the prefix
  235.        [PBD] as in [PBD] TIMESTAMP: External reference ....       
  236.        DO NOT UPGRADE the server. Contact Novell to assist in
  237.        resolving the problem before upgrading. You may continue
  238.        to operate the server as a NetWare 4.0x server until this
  239.        data is corrected.
  240.  
  241.  
  242.  
  243. IV.  STRATEGY FOR MIGRATION
  244.  
  245. Upgrading from NetWare 4.0x to 4.1 is a fast process.  In
  246. general, the process consists of copying new NetWare 4.1
  247. files to the server and restarting.
  248.  
  249. Unless WAN links are involved, this process should take less
  250. than 30 minutes.  Although you can upgrade several servers
  251. at once, if many servers are involved the upgrade could
  252. still take some time.
  253.  
  254. If you will not be running in a mixed environment for an
  255. extended period of time, the order of upgrade may not be
  256. significant.  It is generally best to upgrade all servers in
  257. a given partition.  Until all servers in a given partition
  258. are 4.1, the full benefits will not be realized.
  259.  
  260. When upgrading NetWare 3.x servers to NetWare 4.1 it is best
  261. to upgrade it into a partition in which all servers are
  262. running 4.1.  This ensures proper migration of the bindery
  263. information into the Directory Services database with no
  264. chance for data inconsistencies.
  265.  
  266.  
  267.  
  268. V.   INSTALLING THE NEW DS.NLM ON EXISTING NETWARE 4.1
  269.      SERVERS
  270.  
  271. The 4.89 version of NetWare Directory Services is more
  272. tolerant of data inconsistencies in previous NetWare 4.0x
  273. NDS databases, and will provide better mixed environment
  274. interoperability.
  275.  
  276. Although version 4.89 is designed for mixed environments, all
  277. NetWare 4.1 servers will benefit from running this version.
  278.  
  279. DS.NLM is normally installed as part of a server upgrade or
  280. new install. It also may be loaded and activated on existing
  281. NetWare 4.1 servers without downing the server.  
  282.  
  283.      Procedure
  284.  
  285.      To install the new DS.NLM:
  286.  
  287.      1. Log into the network as ADMIN or a user with rights to
  288.         the SYS:SYSTEM of a newly installed or upgraded file
  289.         server. Locate the file SYS:\SYSTEM\DS.NLM
  290.  
  291.      2. Copy the file to the SYS:SYSTEM directory of the
  292.         NetWare 4.1 file server to be upgraded and overwrite
  293.         the existing file.
  294.  
  295.      3. At the file server console of the server being upgraded
  296.         (or using RCONSOLE) toggle to the system console
  297.         screen.
  298.  
  299.      4. Enter the command "SET DSTRACE = *." and press <Enter>
  300.         to reload the Directory Services without downing the
  301.         server.
  302.  
  303.      5. Repeat the process for each 4.1 server in the network
  304.         which may be running the older version.
  305.  
  306.  
  307.  
  308. VI.  RUNNING A MIXED ENVIRONMENT FOR AN EXTENDED TIME  
  309.  
  310. The remainder of this document applies only to customers who
  311. plan to run NetWare 4.0x and NetWare 4.1 servers on the same
  312. network for an extended time (weeks or months).
  313.  
  314. A number of situations could delay completion of your
  315. upgrade.  These might include:
  316.  
  317.      - Circumstances which prevent you from taking certain
  318.        servers off-line, even for short periods, until
  319.        specifically scheduled.
  320.  
  321.      - Organizational issues where different parts of the tree
  322.        are controlled by different people.
  323.  
  324.      - Running incompatible software that might prevent
  325.        upgrading the server in a timely manner.
  326.  
  327. Although the suggested order below may be used for all
  328. upgrades, it is very important when the upgrade will occur
  329. over an extended time period.
  330.  
  331.      A. SUGGESTED UPGRADE ORDER
  332.  
  333.      1. List all servers to be upgraded and verify that you
  334.         have access rights to each one.
  335.  
  336.      2. For each server, determine if any associated software
  337.         must also be upgraded.
  338.  
  339.      3. For each server, list all replicas on the server,
  340.         indicating if it is a master or a read/write replica.
  341.  
  342.      4. Make a list of all partitions.  For each partition, list
  343.         all servers which have a replica.  Note which server is
  344.         the master.
  345.  
  346.      5. Note which partitions have a large number of replicas
  347.         (more than four or five). Removing these extra copies
  348.         can make the process much faster and simplify your
  349.         planning. Nevertheless, consider any fault tolerance or
  350.         bindery services issues that may exist. Add the copies
  351.         again after the upgrade is complete.
  352.  
  353.      6. Starting at the BOTTOM of your tree structure, select a
  354.         partition to be upgraded.  Remember that the benefits of
  355.         NetWare 4.1 are not fully realized until all servers
  356.         that hold a replica of the partition are upgraded.
  357.  
  358.      7. Select a server with a read/write replica as your first
  359.         server. Using the process detailed above, run the
  360.         DSREPAIR version 2.23e to ensure that the Directory
  361.         Services data is consistent.  If necessary, correct
  362.         errors and rerun DSREPAIR.  Upgrade the server.
  363.  
  364.      8. Upgrade the remaining servers in the partition
  365.         (running DSREPAIR first), upgrading the server 
  366.         holding the master replica last. You want to maintain
  367.         the MASTER replica on a NetWare 4.0x server until all
  368.         servers are upgraded to NetWare 4.1.
  369.  
  370.      9. Select another partition near the bottom of the tree
  371.         structure and upgrade all servers in that partition in
  372.         the same manner. If several partitions are at the same
  373.         level in the tree, select the one with the fewest
  374.         replicas to do first.
  375.  
  376.     10. Continue working up the tree. Because servers in one
  377.         partition will likely contain replicas of another 
  378.         partition base your selections so as to complete all
  379.         servers in a partition whenever possible.
  380.  
  381.     11. If a server which cannot be upgraded quickly contains
  382.         the master replica of a partition, consider moving the
  383.         master replica to a different server (one which will be
  384.         maintained at NetWare 4.0x).
  385.  
  386.     NOTE:
  387.  
  388.      - Partitions not fully upgraded are subject to some
  389.        limitations in further partitioning (as detailed in the
  390.        "VII. Supplement to 'Introduction to NetWare Directory
  391.        Services" section.
  392.  
  393.      - Servers which hold no partition replicas can be upgraded
  394.        at any time.
  395.  
  396.      - NetWare 3.x servers can be upgraded to 4.1 at any time as
  397.        long as the partition to which they are being added has
  398.        been completely upgraded to NetWare 4.1.
  399.  
  400.      B. EXAMPLE
  401.  
  402.      In this example, each server can only be out of service
  403.      late at night on a weekend. Therefore, the upgrade would be
  404.      performed over a period of several weeks or months. 
  405.  
  406.  
  407.      [root]
  408.      |
  409.      |    | cn=A
  410.      +---- ou=ONE           This plus root is a partition
  411.      |    +
  412.      |    | cn=F
  413.      |
  414.      |
  415.      +---- ou=THREE         Containers TWO, THREE, and
  416.      |    +                 FOUR are a partition
  417.      |    | cn=C
  418.      |
  419.      |
  420.      +---- ou=TWO
  421.           +
  422.           | cn=B
  423.           |
  424.           +---- ou=FOUR
  425.           |
  426.           |
  427.           +---- ou=FIVE     Container Five is a partition
  428.               +
  429.               | cn=D
  430.               | cn=E
  431.  
  432.  
  433.             PARTITION
  434.  
  435.      SERVER      ONE      TWO      FIVE
  436.      A            R/W     __        __
  437.      B            M       M         __
  438.      C            R/W     R/W       R/W
  439.      D            __      R/W       R/W
  440.      E            __      R/W       M
  441.      F            __      __        __
  442.  
  443.  
  444.      Example Procedures
  445.  
  446.      1. Select partition five, at the bottom of the tree.
  447.         Run DSREPAIR on server "D" and upgrade it.
  448.         NOTE: This server has a replica of partition TWO which
  449.         is now partially upgraded.
  450.  
  451.      2. Move the Master of FIVE from "E" to "C" and upgrade
  452.         server "E". This only affects partition TWO and FIVE.
  453.         Upgrading server "C" would also affect partition ONE
  454.         because of the placement of the MASTER replica.
  455.  
  456.      3. Perhaps upgrade "F" now, if convenient.
  457.  
  458.      4. Upgrade server "C."
  459.  
  460.      5. Since partition FIVE is complete, but TWO is partially
  461.         complete, next select partition TWO.  (All but server
  462.         "B" have been upgraded.)
  463.  
  464.      6. Move the Master replica of partition ONE from "B" to
  465.         "A." This must be done before server "B" is upgraded. 
  466.         After server "B" is upgraded to NetWare 4.1, you cannot
  467.         move the MASTER replica to server "A" which is still a 
  468.         NetWare 4.0x server.
  469.  
  470.      7.  Upgrade server "B."
  471.  
  472.      8.  Complete the upgrade with server "A."
  473.  
  474.      NOTE: moving the master replica is only necessary if there
  475.      is any possibility that partition operations might need to
  476.      be done unexpectedly before you complete the upgrade.  Once
  477.      a partition is fully upgraded there are no partition
  478.      limitations and the full benefits of 4.1 are realized.
  479.  
  480.  
  481.  
  482. VII. SUPPLEMENT TO "INTRODUCTION TO NETWARE DIRECTORY SERVICES"
  483.  
  484.      A. PARTITIONING RULES FOR MIXED NETWARE 4.1 AND 4.0x
  485.         NETWORKS
  486.  
  487.      If, when upgrading a NetWare 4.0x Directory tree to NetWare
  488.      4.1, you are unable to upgrade all servers to 4.1 at the
  489.      same time, the following partitioning rules apply to Add,
  490.      Split, Join, and Remove Partition and Change Replica Type
  491.      operations.
  492.  
  493.      1. If the Master replica of a partition resides on a
  494.         NetWare 4.0x server, then all partition related
  495.         operations can be performed in a mixed environment.
  496.  
  497.      2. Once the Master replica of a partition has been moved to
  498.         a 4.1 server, the Master replica cannot be moved back
  499.         to a 4.0x server.  Also Add, Split, and Join partition
  500.         operations no longer works for that partition until all
  501.         servers have been upgraded to 4.1 or the 4.0x servers
  502.         containing replicas of the partition have had their
  503.         replicas removed.
  504.  
  505.      3. A subtle problem occurs with Subordinate References on
  506.         4.0x servers.  If a master replica of a partition
  507.         resides on a 4.1  server,  the Add, Split and Join
  508.         partition operations will not work if a 4.0x server
  509.         contains a Subordinate Reference of the partition in
  510.         question.
  511.  
  512.      4. The Remove Partition operation will always work
  513.         regardless of where the Master replica of the partition
  514.         exists.
  515.  
  516.      5. The Change Replica Type operation will always work in a
  517.         mixed environment except in the case where the Master
  518.         replica has been moved to a 4.1 server.
  519.  
  520.     In this case the master replica can only be moved to another
  521.     4.1 server.
  522.  
  523.     However, any 4.0x servers with replicas of the partition can
  524.     be changed to Read Write or Read only.
  525.  
  526.     The following matrix shows what partition operations are 
  527.     possible in a mixed environment.  The Master column
  528.     indicates  the version of the server containing the master
  529.     replica of the  partition.
  530.  
  531.     Partition Operation                   Server Versions
  532.                                 Master  4.01    4.02    4.1
  533.     _______________________________________________________
  534.      Add Replica              | 4.01    OK      OK      OK
  535.                               | 4.02    OK      OK      OK
  536.                               | 4.1  (NOT OK) (NOT OK)  OK
  537.  
  538.      Split Partition          | 4.01    OK      OK      OK
  539.                               | 4.02    OK      OK      OK
  540.                               | 4.10 (NOT OK) (NOT OK)  OK
  541.  
  542.      Join Partition           | 4.01    OK      OK      OK
  543.                               | 4.02    OK      OK      OK
  544.                               | 4.10 (NOT OK) (NOT OK)  OK
  545.  
  546.      Remove Partition         | 4.01    OK      OK      OK
  547.                               | 4.02    OK      OK      OK
  548.                               | 4.10    OK      OK      OK
  549.  
  550.      Change Replica Type      | 4.01
  551.                               | 4.02      ( See number 5 above)
  552.                               | 4.10
  553.  
  554.      B. THE DISTINGUISHED NAME OF AN OBJECT CANNOT EXCEED 256
  555.         CHARACTERS
  556.  
  557.      When leaf objects are created, they are checked to ensure
  558.      that the maximum name length of the Distinguished Name is
  559.      not exceeded.  However, it is possible to go back and
  560.      rename a leaf object with a longer name and cause the
  561.      Distinguished Name to exceed 256 characters.
  562.  
  563.      The following is an example of a Distinguished Name:
  564.  
  565.      CN=Morty Hansen.OU=Toy Sales Department.OU=Sales
  566.      Department.O=Fun Toys 4 U.C=US.TOYS_TREE 
  567.  
  568.      Each ".OU=" is counted in the total character count,
  569.      including the name of the NDS tree.
  570.  
  571.  
  572.      C. INACCURATE ILLUSTRATION OF PARTITION REPLICATION
  573.  
  574.      Figures 6-2 and 6-3 in Chapter 6, of "Introduction to
  575.      NetWare Directory Services" indicate that more than one
  576.      Master replica can exist for a particular partition. The
  577.      figures should illustrate that only one Master replica can
  578.      exist per partition.
  579.  
  580.  
  581.      D. DSMERGE
  582.  
  583.      If you merge several trees together, you will need to
  584.      reassign administrative rights to the supervisor of the
  585.      first tree.
  586.  
  587.      For example, if Tree1 is merged into Tree2, which is then
  588.      merged into Tree3, the ADMIN on Tree1 loses its
  589.      administrative rights.  Using the ADMIN from Tree2 or
  590.      Tree3, reassign administrative rights to ADMIN on Tree1.
  591.  
  592. ================================================================
  593. Disclaimer     
  594.  
  595. Novell, Inc. makes no representations or warranties with respect
  596. to the contents or use of this document, and specifically
  597. disclaims any express or implied warranties of merchantability
  598. or fitness for any particular purpose. Further, Novell, Inc.
  599. reserves the right to revise this publication and to make 
  600. changes to its content, at any time, without obligation to
  601. notify any person or entity of such revisions or changes.
  602.  
  603. Novell, Inc., makes no representations or warranties with
  604. respect to any NetWare software, and specifically disclaims any
  605. express or implied warranties of merchantability, title, or
  606. fitness for a particular purpose.  Distribution of any 
  607. NetWare software is forbidden without the express written
  608. consent of Novell, Inc.
  609.  
  610. Further, Novell reserves the right to discontinue distribution
  611. of any NetWare software. 
  612.  
  613. Novell is not responsible for lost profits or revenue, loss of
  614. use of the software, loss of data, costs of recreating lost
  615. data, the cost of any substitute equipment or program, or claims
  616. by any party other than you.
  617.  
  618. Novell strongly recommends a backup be made before any software
  619. is installed. Technical support for this software may be
  620. provided at the discretion of Novell.
  621.  
  622. Trademarks
  623.  
  624. Novell, Inc. has attempted to supply trademark information about
  625. company names, products, and services mentioned in this
  626. document.
  627.  
  628. The following list of trademarks was derived from various
  629. sources.
  630.  
  631. Novell and NetWare are registered trademarks NetWare 4.01,
  632. NetWare 4.02, NetWare 4, NetWare Client, NetWare Directory
  633. Services and NDS, and N.M. are trademarks of Novell, Inc.
  634.  
  635. All other products and company names are trademarks or
  636. registered trademarks of their respective holders.
  637.  
  638.