Implementing Secondary SLP Scopes
Novell Cool Solutions: Feature
Digg This -
Posted: 29 Mar 2006
ProblemIn my organization that spans multiple WAN links (each with 1,000 or more users), login issues occur when the WAN links go down. Logins either fail or are extremely slow as clients try to reach the SLP DA's that are back at the hub sites. Currently there are two DA's at hub sites, and the desire is to allow better access to local resources in the event of WAN link failure - without having to allow for the failover to multicasting. Also, we need to mimimize replication across WAN links (thus not using multiple DA's in a flat structure, which would require synchronization of all services across the tree).
The solution is to create Scopes and DA's at lower OU's in the tree that will be aware of the local services, so logins and drive mappings will be seamless in the advent of WAN failure, all the while continuing to have the services available at the Hub DA's. All ZEN settings, Search Policy settings, etc., have been checked.
When implementing Secondary SLP scopes, there are several issues that have to be considered. Following is a summary of the areas which would not be affected and the changes that would have to be made for this to be implemented at a Remote Site. All of the changes occur with objects at the Remote OU or below.
A location with only one Netware server would become a DA. In locations with multiple servers, the chosen server would most likely be the one that is used the most. Other servers at the location would be modified slightly as discussed below. There would be two NDS objects created for each of the locations - a NEW SCOPE and an SLPDA object (using NWADM, ConsoleOne with proper snapins, or iManager). A "Planned Sequence of Events" follows at the end of this article.
ROOT_Scope and Current DA's
Currently, a ROOT_SCOPE exists in our eDirectory tree with 2 DA's, one at each of our two Hub sites. No changes would be made to the existing setup. The scope and existing DA's would remain unchanged. Also, no new DA's would be used at this level.
A new scope would be created in the Remote OU. The suggested naming convention would be RemoteOU_SCOPE (e.g., DUBLIN_SCOPE). There are several reasons for this: it is located at the NDS location which it will be servicing, servers come and go, the names sometimes may change, etc.
An SLPDA object would be created in the Remote OU. The suggested naming convention would be RemoteOU_SLPDA (e.g., DUBLIN_SLPDA). On this NDS object there are two settings that need to be made: an association to the server that will become the Remote DA, and an association to the new Remote Scope. Note: Do not associate to the ROOT_SCOPE here.
Netware Server Settings for the New Scope and DA
On the server that will be the DA (which must contain the Master or a RW replica of the Remote Site's partition), several settings are changed.
1. In MONITOR > SERVER PARAMETERS > SERVICE LOCATION PROTOCOL enter the new scope name before the current ROOT_SCOPE entry (e.g., DUBLIN_SCOPE, ROOT_SCOPE).
2. Edit the SYS:\ETC\SLP.CFG file to include the IP address of itself as a DA in the proper syntax. This would be above the current entries for the DA's, in the same syntax that they use.
3. Load SLPDA on the server and enter it into the AUTOEXEC.NCF.
On the others servers at the remote site, two changes have to be made.
1. In MONITOR, the new scope name must be added before the current ROOT_SCOPE entry (e.g, DUBLIN_SCOPE, ROOT_SCOPE).
2. Edit the SYS:\ETC\SLP.CFG file to include the IP address of the in-district server to be used as a DA in the proper syntax. This would be above the current entries for the DA's, with the same syntax they use.
There are two items that have to be changed on the client. It is desirable to have this distributed via policies, although this may not be possible in all cases. The new DA and Scope would be distributed and placed at the top of the respective locations under the Service Location tab of the Novell Client. This would cause them to be contacted before the workstation would attempt to contact the DA's and Scope that are off-site.
Planned Sequence of Events
Note: It is important to verify that the operation of each step is successful before moving to the next step.
1. Create Remote Scope and SLPDA Objects.
2. Associate Server and Remote Scope to the Remote SLPDA.
3. On Remote DA, make changes to Monitor, SLP.CFG, and AUTOEXEC.NCF as described above.
4. Reboot the server (that will host the SLPDA) and verify SLPDA loads.
5. Type "DISPLAY SLP DA'S" on the Remote DA and verify it shows Version 2, showing DA's and Scopes properly and with an active status. (If there are problems, check for typos in the above entries). The ROOT_SCOPE DA'S and the Remote DA should show with appropriate Scope associations. On the Remote DA you will also see a Loopback entry.
6. On other Remote Servers (if present), make the changes described above to Monitor and SLP.CFG settings. It probably seems obvious, but there would be no Loopback here.
7. On the other Remote servers (if present), type "SET SLP RESET = ON".
8. On the other Remote servers (if present), type "DISPLAY SLP DA'S" and verify it shows Version 2, showing DA's and Scopes properly. (If there are problems, check for typos in above entries). The ROOT_SCOPE DA'S and the Remote DA should appear with appropriate Scope associations and active status.
9. Verify in NWADM, ConsoleOne, or iManager that you see the expected services shown under the Remote Scope you have created. You should only see services that are associated with the servers you have specified above - the REMOTE_SCOPE should show services for all the servers located AT THE Remote site, but not for any services hosted elsewhere.
10. After verifying steps 5-9, distribute the specified entries to the associated clients in the order described above, via policies, ZEN, or other method.
The setup is now complete.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com