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.