home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Network Support Encyclopedia 96-1
/
novell-nsepro-1996-1-cd2.iso
/
download
/
netware
/
nns.exe
/
NNSSTMT3.DOC
< prev
Wrap
Text File
|
1994-01-25
|
8KB
|
162 lines
January 24, 1994
The following Marketing and Support statement is being provided to
customers currently using or considering using Novell's NetWare
Name Service (NNS).
Audience: Interested NNS customers upon request, NetWire, Product
Information and Technical Support for release to
customers inquiring about Novell's NNS Strategies.
- NetWare Name Service (NNS) was first released to market in
December of 1990. Since that date many sites have installed
NNS primarily for the purpose of simplifying tasks related to
network administration.
- NNS was designed as an interim solution for customers wanting
a simple naming service prior to the release of NetWare 4,
which began shipping April 1993. NNS was not designed as a
complete solution nor was it intended to be an alternative to
Novell's Directory Service. For example, NNS does not offer
time synchronization services, a vital part of NetWare 4's
Directory Services which resolves conflicts when administering
the directory services database.
- NetWare 2.x/3.x customers who have not deployed NNS, yet who
are planning to upgrade to NetWare 4.x in the future, are
encouraged to upgrade directly to NetWare 4 rather than use
NNS as a transition solution to get to NetWare's Directory
Services.
- At the present time, Novell has no plans to release further
enhancements to NNS. Reported NNS bugs will continue to be
addressed unless the reported problem requires a design change
to NNS.
- Currently, technical support for NNS is provided by
1-800-NETWARE (internationally 801-429-5228). Engineering
support, which includes bug fixes to NNS utilities, is also
available through 1-800-NETWARE (internationally
801-429-5228). Design changes and product enhancements are no
longer available for NNS.
- NetWare 4 was released in April, 1993. NNS customers have
until October 31, 1994 to migrate their NNS domains to NetWare
4. At that time all Technical and Engineering support for
NNS, including bug fixes, will be withdrawn.
The following guidelines and restrictions apply to NNS. These are
additional guidelines to those contained in the NNS documentation.
1. Synchronization for binderies within an NNS domain should be
performed from a single administration workstation at a time.
Simultaneous synchronization from multiple nodes can cause
bindery corruption. Consult the NNS manual for a list of
utilities that may synchronize the binderies within an NNS
domain.
2. NNS employs no real time synchronization services to manage
bindery modifications in the NNS environment. Multiple points
of administration for a single NNS domain should be avoided.
Locating NNS domains across remote locations should also be
avoided.
3. NNS "toggles" connection 8 when administering domains with
more than 8 servers. (i.e. connection 8 is used to update the
8th server in the domain then the 9th, then the 10th, etc.)
Care should be taken to insure that connection 8 is free
before initiating domain administration tasks for domains with
greater than 8 servers. Due to the number of difficulties
experienced by some NNS sites, Novell no longer recommends
extending NNS domains to include more than eight servers per
domain. Active NNS sites with more than 8 servers per domain
are encouraged to consider reducing the number of servers in
their domains.
4. Due to the number of difficulties experienced by some NNS
sites, and also due to performance issues related to domains
with large numbers of objects, Novell no longer recommends
extending NNS domains to include more than 1,000 objects
within a single domain. In order to facilitate manageability,
NNS sites with more than 1,000 objects per domain are
encouraged to consider reducing the number of objects in their
domains.
5. Adding a file server to a domain or synchronizing file servers
within a domain has been known to cause random password
assignment to user accounts.
6. Synchronization performance on an NNS network may be affected
by a number of factors. These include:
- the number of file servers in the domain
- the number of bindery objects (users and groups)
within the domain
- the physical layout of the network
- the speed of both the server and the client
involved in the synchronization process
Using NNS with a large number of file servers, a large number
of bindery objects, or in a WAN environment is not recommended
and can result in poor performance. The use of multiple
domains may help alleviate these problems.
7. Due to potential conflicts in bindery administration, NNS may
be susceptible to bindery corruption. Bindery corruption on
file servers within NNS domains can manifest itself in a
variety of ways. Network administrators should be especially
vigilant to make sure their binderies are free of corruption.
If bindery corruption occurs, administrators should use the
latest version of bindfix off of NetWire to solve the problem.
8. Some sites utilize NNS domains primarily to allow users within
the domain to submit print jobs to a single domain print queue
which is then serviced by a single domain printer. Such sites
may also wish to consider utilizing printing services, such as
the NetWare Print Server NLM, to concurrently service print
queues located on different servers.
The following guidelines and restrictions apply when using NNS in
conjunction with Novell's recently released NCP Security Signature.
These are additional guidelines to those contained in the NNS
instruction manual and the NCP Security Signature documentation.
Failure to follow these guidelines may result in binderies within
an NNS domain becoming "out of sync".
9. When any server in an NNS domain is set to NCP Security
Signature level 3, all clients within the domain should be set
to level 1 or higher. Clients running at level 0 cannot
synchronize servers running at level 3.
10. Likewise, when any client in an NNS domain is set to NCP
Security Signature level 3, all servers within the domain
should be set to level 1 or higher. Servers running at level
0 cannot be administered by clients running at level 3.
The following guidelines apply to NNS domains that will be upgraded
to NetWare 4.x Directory Services (NDS). Please refer to NetWare
4.x marketing and technical information and related product
documentation for a better understanding of the concepts presented
here.
11. With the release of NetWare 4.0, Novell has withdrawn NNS from
the price list. NNS was intended as an interim naming service
for those customers wishing to administer multiple 3.x and 2.x
servers. It was not intended that long term support be
provided to NNS.
12. Novell will end technical support for NNS on October 31, 1994.
Existing NNS sites have until October 31, 1994 to fully
migrate their NNS domains to NetWare 4.x. Customers with
existing NNS licenses are encouraged to take this into account
when adding new NNS domains or adding additional servers and
users to existing NNS domains.
13. To facilitate manageability and to avoid service problems when
upgrading NNS to NDS, Novell recommends that all servers
within the NNS domain be migrated to 4.x with the same time
frame. To simplify the upgrade to NDS, customers using NNS
are encouraged to plan and properly size their NNS domains
prior to beginning a migration to NDS. If an entire NNS
domain cannot be migrated to NDS within the same time frame,
customers may wish to resize the NNS domain prior to doing the
upgrade to NetWare 4.x.