How to migrate to a named scope without restarting all SAs

CUSTOMER SCENARIO
NetWare 5.1 Servers
Central location with many servers
Many remote sites with a single server and no local administrator.

Currently using an UNSCOPED scope

Preparing to introduce the first NetWare 6 server in to the tree and would like to implement a named scope for this purpose.

Currently if the name of the scope changes it is necessary to restart the DA first followed by all SAs.
This restart is necessary following a scope name change as the scope name information that is stored in the NetWare servers registry is only read once upon server start up by the SLP related NLMs which are located in the C:\NWSERVER directory.
After the SA Default Lifetime amount has expired, if the SAs are not restarted and scope name has been changed the SAs will fail to re-register with the DA and the new scope.
The set parameter:
SET SA Default Lifetime = 3600 which is the default
This can be changed within Monitor - Server parameter - Service Location Parameters
How to migrate to a named scope without restarting all SAs

In CSP10 (Consolidated Support Pack 10 - NetWare 6 SP4 and NetWare 5.1 SP7) it will no longer be necessary to reboot all servers when modifying the name of a scope.
WORK AROUND
If it is not possible for the customer to reboot all servers in their environment in such a short time period, it is possible to do the following:
1) NetWare 5.1 server DA servicing an UNSCOPED scope
2) Configure the NetWare 6 servers as they are introduced in to the tree in the following manner:
SET SLP DA DISCOVERY OPTIONS=4
Edit SYS:\SYSTEM\SLP.CFG and enter the NetWare 5.1 DA ipaddress
SET SLP RESET=ON
The NetWare 6 server will register with the NetWare 5.1 DA servicing the UNSCOPED scope without a reboot of the server.
To double check this type:
display slp services bindery.novell and look for the NetWare 6 server.

By default a NetWare 6 SLPV2 server will communicate using both SLP V1 and SLP V2.
This can be seen with the SET parameter:
SET SLP Version Mode = 0, 1, 2
where 0 = SLPV1 and SLPV2 or both - this is the default
where 1 = SLPV1 only
where 2 = SLPV2 only
This can be changed within Monitor - Server parameter - Service Location Parameters.
Note Monitor needs to be loaded with the !h, i.e. Monitor !h

3) Once all servers excluding the NetWare 5.1 SLPDA are running NetWare 6, upgrade the last NetWare 5.1 SLPDA server to NetWare 6.
4) Delete the old UNSCOPED scope and its objects
5) load SLPDA and create a "Default" scope.
Note the "Default" scope is the default named scope for SLPV2.
6) Enter SLP RESET=ON on all the other NetWare 6 servers.

Please note that there is a 64K limitation with SLP V1 which can effect very large customers only.

- When a UserAgent (this could be a client or server) requests information about a specific service from a Directory Agent (DA), it will send a UDP SLP Service Type request asking for all services of the same type such as bindery.novell (bindery.novell is the service name for NDS).
- The DA will respond with a UDP packet.
- If there are so many bindery.novell services registered in SLP that they do not all fit within this 1 UDP reply packet then a overflow bit is set by the DA.
- The user agent will then open a TCP connection with the DA and ask for all the bindery.novell services again.
The limitation here is that a total of 64K of data is all the DA can send to the client via this TCP connection.
If there is more than 64K of a certain service type then it will be cut off.

The SLP v1.0 RFC 2165 limitation is that the response "length field" is only 16 bits, so the over flow is for up to 64k bytes.
In version 2 of SLP the length field has been changed to 24 bits, thus allowing for up to a 16MB response datagram.

For further information about this and whether you are likely to be affected please see KB 10024584 - What is the 64K limitation with SLP? or go to the following URL:

TID 10024584 - What is the 64K limitation with SLP?

Formerly known as TID# 10081615