Integrating Systems Management Server 2.0 with Novell NetWare

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft® Systems Management Server

The Technical Readiness Series

Eric Z. Leonard Microsoft Consulting Services
Jim Lathrop
Technology Specialist
Gulf States District

On This Page

Acknowledgments
Introduction
Introduction to Novell NetWare
Deployment Planning Information
Installation and Configuration
Appendix A: NetWare Logon Script Examples
Appendix B: Systems Management Server 2.0 NDS Components
Appendix C: Setting Up Novell NDS Integration With Systems Management Server
Appendix D: Setting Up Novell Bindery Integration with Systems Management Server
Appendix E: Troubleshooting
Known Issues and Concerns

Acknowledgments

The authors would like to thank the following people for their contributions to this white paper: The entire Systems Management Server development team, Tony de Freitas, Steve May, David Randall, Dan Truax, Luke Packard, Jennifer Harrison, Jose Ward, Jim Bonnell, Jack Miller, and Sandra McCarthy.

Introduction

This document describes the concepts and systems requirements needed to install Microsoft® Systems Management Server version 2.0 and integrate it into a NetWare environment. More specifically, this document will help you deploy Systems Management Server 2.0 in a Novell NetWare 3*.x* (bindery) and NetWare 4*.x* (NetWare Directory Service [NDS] and bindery emulation) environment. Requirements such as supported software versions, security, and the processes required to implement the Systems Management Server 2.0 feature set on the Novell NetWare platform are documented thoroughly.

The following topics are included in this document:

• Successful deployment of Systems Management Server 2.0 in a mixed Microsoft ® Windows NT® and Novell NetWare environment.

• Identification of Novell NetWare user permissions, object permissions, supported client redirectors, required server software versions, and NDS name space specifications in the NetWare environment, and how these components or architectures interface with Systems Management Server 2.0 components.

• Identification of Systems Management Server 2.0 configuration requirements and feature set offerings for the Novell platform.

Note: This document is intended to supplement the Systems Management Server 2.0 Administrator's Guide and should not be viewed as a replacement.

Systems Management Server Configuration Prerequisites

Before implementing Systems Management Server in a NetWare environment, it is a good practice to have already performed the following Systems Management Server configuration tasks in a Windows NT environment so you are familiar with the Systems Management Server environment:

• Installed a Systems Management Server site server.

• Configured a logon point, client access point, and distribution point in a Windows environment.

• Discovered and installed a Systems Management Server client.

• Distributed software to a client.

Introduction to Novell NetWare

Novell Bindery and Bindery Emulation Overview

NetWare 3*.x* servers are called bindery servers. Bindery servers do not have a Directory Service that ties them all together. Each server is stand-alone and maintains its own database of users (the bindery). A bindery emulation server is a NetWare 4*.x* server emulating a bindery (3*.x*) server. Bindery emulation is a mode of NDS by which older applications that require the bindery can communicate with NDS.

Novell NetWare Directory Services Overview

All NetWare 4*.x* servers on the same network have information on all network resources on the network because they all use the same directory. Thus, NDS creates a single, unified network by providing a single point for accessing and managing most network resources.

The network administrator does not need to know which NetWare server provides a particular resource. Each network resources has an entry in the Directory Service with a unique name. A user simply requests the resource by this unique name; any NetWare 4.x server on the same network can connect the user with the resource (granted that he or she has rights to that object).

Composition of the Directory

The Directory consists of objects, properties, and values.

Objects

NDS represents each network resource as an object in the Directory. Hence, an object is a unit of information about a resource, comparable to a record in a conventional database.

Properties and Values

Each NDS object consists of categories of information, called properties, that can be recorded about the resource. Similar types of objects have the same properties; different types of objects may or may not have the same properties. A property value is the data within a property.

For example, a printer is represented as a Printer object. The properties associated with the Printer object include Name, Description, and Location. The values for each of these Properties could be HPPCCT, HPIII PostScript, and Room 305, respectively.

Classes of NDS Objects

NDS objects can be divided into three classes or types: [Root], Container, and Leaf.

[Root]

The [Root] object represents the highest level in the Directory tree (traditionally drawn as an upside-down hierarchical tree structure with the root of the tree at the top of the page). The [Root] provides access to different Country and Organization objects. The network administrator can make trustee assignments and grant rights to the entire Directory tree from the [Root]. Each Directory can have only one [Root].

The [Root] object is a placeholder; it contains no information. Country, Organization, and Alias objects can be created directly under the [Root] object. The [Root] object cannot be deleted, renamed, or moved. The square brackets ( [ ] ) are mandatory when referring to this object.

Container Objects

Container objects hold, or contain, Leaf or other container objects. They are used to logically group and organize the objects of your Directory. They can be used to represent countries, companies, departments, areas of responsibility, workgroups, or shared resources as required.

Object	Definition
Country (C )	Designates the countries/regions where your network resides, and organizes other Directory objects within the country/region. The use of the Country object is optional.
Organization (O)	Represents an organization; for example, a company, a university, or a department. It is the first level, other than Alias objects, that can contain Leaf objects. (An Alias object is simply a pointer to another object.) The tree must have at least one Organization object.
Organization Unit (OU)	Represents a division, a business unit, a project team, or a department within an organization. It is a level below the Organization object, and helps to further organize your Leaf objects.

Leaf Objects

Leaf objects represent network resources, such as users, groups, organization roles, printers, print servers, print queues, NetWare servers, and NetWare volumes.

Directory Tree Structure

The Directory tree is the hierarchical structure that stores and organizes objects in the Directory. It is composed of the [Root] and container objects.

The Directory tree structure is similar to the tree structure found in the MS-DOS® file system. The top of the tree is called the [Root]. Container objects, analogous to directories, are placed in the [Root] or in other containers. (A container is called a parent object if it contains other objects.) Leaf objects, analogous to files, are placed within containers.

The Directory tree structure differs from the MS-DOS file system structure because different NDS container objects have restrictions on where they can be placed and what can be placed in them.

Each class of container object has different rules that define what it can contain and where it can be located in the Directory tree. Each class has different properties.

Container object	Can exist in	Can contain	Example
Country	[Root]	Organization Alias	US FR
Organization	[Root] Country	Organization Unit All Leaf objects	Microsoft UCLA
Organization Unit	Organization Organization Unit	Organization Unit All Leaf objects	Accounting ITG

The rules limiting what a container can hold and where it can be held force specific Directory tree structures. The figure below illustrates these rules with three possible Directory tree structures.

[Root] | Organization | Leaf Objects

[Root] | Organization | Organization Unit | Leaf Objects

[Root] | Country | Organization | Organization Unit | Leaf Objects

To access a network resource, such as a network printer, the user must request the object by its NetWare Directory Services object name. NDS (or more specifically, whichever NetWare server responds to the request) locates the requested object in the Directory. It also checks the Directory to verify that the user is a valid user and has rights (permissions) to use the object. Based on the property values in the object, NDS locates and connects the user with the resource.

Accessing NDS

A multiple-container Directory tree (as opposed to a single-container Bindery system) probably has the greatest impact on how network resources are accessed because of the following:

• Objects are no longer in a single container.

• NDS does not search the entire Directory tree to find an object.

For these reasons, NDS requires precise information to find the correct object. You, the user, or your workstation, must provide NDS with enough information to locate the object in the Directory tree. This information comes in the form of an appropriate object name. To correctly access network resources, you must provide the correct object name that exactly identifies which object in the entire Directory tree you want.

This information can be provided using either of the following:

• Distinguished Name

• Relative Distinguished Name

To understand the difference between the Distinguished Name and the Relative Distinguished Name, you must be familiar with the terminology associated with the naming objects, as listed in the following figure, and explained in the following subsections.

Common Name

A Leaf object's common name is the name shown next to the Leaf object in the Directory tree. A common name is a "local" name for the object. It does not contain any position information.

Context

Context is an object's position in the Directory tree. It is a list of the container objects leading from the object to the [Root]. (Locating an object through its context is similar to locating a file using the directory path).

Distinguished Name

A Distinguished Name starts with a leading period. The objects in the name are separated by periods; similar to the backslash used in MS-DOS paths. Trailing periods cannot be used in a Distinguished Name.

An object's Distinguished Name is a combination of its common name and its context.

For example, in the figure above, the Distinguished Name for the User object, DavidJohnson, in the Organization Unit XYZ Corp, in the Organization ABC, is as follows:

.CN=DavidJohnson.OU=XYZ.O=ABC

The Distinguished Name for the User object DavidJohnson, in the Organization ABC, is as follows:

.CN=DavidJohnson.O=ABC

Current Context

The user's current context can affect how much of an object's Distinguished Name you must provide with a command to access the resource.

Current context (sometimes called name context) can be thought of as your current position in the Directory tree. In the Novell client, the current context setting (name context) identifies the default NDS Container for your workstation.

Relative Distinguished Name

A relative Distinguished Name lists the path of objects leading from the objects being named to the current context. A relative Distinguished Name does not start with a leading period, but the objects in the name are separated by periods. Trailing periods can also be used.

When you use a relative Distinguished Name, NDS builds a Distinguished Name for it. This is accomplished by appending the relative Distinguished Name to the current context, as shown in the following statement:

Relative Distinguished Name + Current Context = Distinguished Name

In the following examples, a different current context creates a different Distinguished Name when the same relative Distinguished Name is submitted.

Name submitted	Current context	Resulting Distinguished Name
CN=DavidJohnson	O=ABC	.CN=DavidJohnson.O=ABC
CN=DavidJohnson	OU=XYZ.O=ABC	.CN=DavidJohnson.OU=XYZ.O=ABC

The following table lists the attribute type abbreviations.

Attribute type abbreviation	Object
C	Country
O	Organization
OU	Organization Unit
CN (Common Name)	All Leaf objects

Typeless Naming

A typeless name does not include the object attribute type. For example, the typeless distinguished name for .CN=DavidJohnson.OU=XYZ.O=ABC is as follows:

.DavidJohnson.XYZ.ABC

Important: Use the typeless naming convention when configuring NDS site systems in the Systems Management Server Administrator program.

Supported NDS Naming Conventions

For a Systems Management Server 2.0 site to successfully create a client access point, logon point, and distribution point on an NDS volume, there are certain naming conventions that must be followed.

Tree Names

• The NDS tree can contain up to 32 ASCII characters. Accepted characters are A through Z, 0 through 9, the hyphen (-), and the underscore (_).

• The NDS tree cannot start or end in an underscore (_). Nor can it contain two consecutive underscores (__).

• The NDS tree name cannot contain any spaces.

Container and Volume Names

Container and volume names may not contain any:

• Slashes (/)

• Backslashes (\)

• Colons (:)

• Commas (,)

• Asterisks (*)

• Question marks (?)

Object names are not case sensitive.

Distinguished Names must contain an O (Organization object — top level of Systems Management Server tree).

Suggestions:

• Do not use Systems Management Server or Microsoft as your tree name, Organization, or Organizational Unit name.

• Place servers and people in the same "area" of the directory.

• Plan your tree before implementing.

NetWare NDS Rights

Directory Rights

Directory rights apply to the directory in the NetWare file system they are assigned to, as well as to all files and subdirectories in that directory (unless redefined at the file or subdirectory level).

Directory rights are a part of the file system and they are not assigned to NDS objects. However, a User object can be granted Directory rights to a directory on a volume. For example, the User object, DavidJohnson, can be granted permissions to a specific directory on a server volume.

Right	Description
Supervisor (S)	Grants all rights to the directory, its files, and subdirectories. The Supervisor right can't be blocked by an Inherited Rights Filter. Users with this right can grant other users rights to the directory, its files, and subdirectories.
Read (R)	Grants the right to open files in the directory, and read the contents or run the programs.
Create (C)	Grants the right to create new files and subdirectories in the directory. If Create is the only right granted to a trustee for the directory, and no other rights are granted below the directory, a drop box directory is created. In a drop box directory, you can create a file and write to it. After the file is closed, however, only a trustee with more rights than Create can see or update the file. You can copy files or subdirectories into the directory and assume ownership of them, but other users' rights are revoked.
Write (W)	Grants the right to open and change the contents of files in the directory.
Erase (E)	Grants the right to delete the directory, its files, and subdirectories.
Modify (M)	Grants the right to change the attributes or name of the directory and of its files and subdirectories, but does not grant the right to change the contents of them. (Changing the contents requires the Write right.)
File Scan (F)	Grants the right to see the directory and its files with the dir or ndir command.
Access Control ( A)	Grants the right to change the trustee assignments and the Inherited Rights Filter of the directory, and of its files and subdirectories.

File Rights

File rights apply only to the file they are assigned to. A trustee can also inherit rights to a file from the directory above the file.

Right	Description
Supervisor (S)	Grants all rights to the file. The Supervisor file right cannot be blocked with an Inherited Rights Filter. Users who have this right can also grant other users any rights to the file, and can change the file's Inherited Rights Filter.
Read (R)	Grants the right to open and read the file.
Create (C)	Grants the right to create a file, and to salvage a file after it has been deleted.
Write (W)	Grants the right to open and write to an existing file.
Erase (E)	Grants the right to erase (delete) the file.
Modify (M)	Grants the right to change the attributes and name of the file, but does not grant the right to change its contents. (Changing the contents requires the Write right.)
File Scan (F)	Grants the right to see the file with the ndir directory command, including the directory structure from that file to the root directory.
Access Control (A)	Grants the right to change the trustee assignments and the Inherited Rights Filter of the file.

Object Rights

Object rights apply to NDS objects. Object rights do not affect the properties of an object (see "Property Rights" later in this section). A trustee can inherit rights to an object from the object above it.

Right	Description
Supervisor (S)	Grants all access privileges. A trustee with the Supervisor object right also has unrestricted access to all properties. The Supervisor object right can be blocked by an Inherited Rights Filter below the object where the Supervisor right is granted.
Browse (B)	Grants the right to see this object in the Directory tree.
Create (C)	Grants the right to create a new object below this object in the Directory tree. Rights are not defined for the new object. This right is only available on container objects because non-container objects cannot have subordinates.
Delete (D)	Grants the right to delete the object from the Directory tree. Objects that have subordinates cannot be deleted (unless subordinates are deleted first).
Rename (R)	Grants the right to change the name of the object, in effect changing the naming property. This changes the object's complete name.

Property Rights

Property rights apply to the properties of an NDS object. Rights can be assigned to all properties as a whole, or to selected properties.

Right	Description
Supervisor	Grants all rights to the property. The Supervisor property right can be blocked by an object's Inherited Rights Filter.
Compare	Grants the right to compare any value to a value of the property. With the Compare right, an operation can return True or False, but you cannot see the value of the property. The Read right includes the Compare right.
Read	Grants the right to read the values of the property. Compare is a subset of Read. If the Read right is given, Compare operations are also allowed.
Write	Grants the rights to add, change, or remove any values of the property. The Write right includes the Add or Delete Self right.
Add or Delete Self	Grants a trustee the right to add or remove itself as a value of the property. The trustee cannot affect any other values of the property. This right is only meaningful for properties that contain object names as values, such as group membership lists or mailing lists. The Write right includes Add or Delete Self.

Deployment Planning Information

Feature List for Clients Using Novell NetWare Networking Software

The following table shows the Systems Management Server features for clients running each of the supported Systems Management Server client types and using NetWare networking software.

Client	Hardware Inventory	Software Inventory	Software Distribution	Remote Control	Network Monitor	Software Metering
Windows® 3.1
Windows® for Workgroups 3.11
Windows® 95
Windows® 98
Windows® NT 3.51, Service Pack 5a
Windows NT® 4.0, Service Pack 3 or later
Windows NT® 4.0, Enterprise Edition
Windows® 2000

Important: Hardware Inventory free disk space information is not available on Novell servers. However, free space on servers that have client access points and distribution points is available under Site System Status.

Supported Platforms for Systems Management Server Site System Roles

Systems Management Server 2.0 Site System Role	Novell NetWare
	Bindery 3.x	NDS 4.x
Primary site server
Secondary site server
Site or software metering database server (SQL Server 6.5, Service Pack 4 or later )
Site or software metering database server (SQL Server 6.5, Enterprise Edition, Service Pack 4 or later)
Site database server (SQL Server 7.0)
Logon point
Client access point
Distribution point
Software metering server
Component servers

Important: Please take note of the following points:

• Appendix A of the Systems Management Server Administrator's Guide outlines server requirements for Windows NT Site Systems Roles.

• Because there is no intraNetWare client for the Alpha platform, no NDS logon points, client access points, or distribution points can be created when a primary site is installed on an Alpha computer.

• Running bindery emulation and NDS on a single Novell server requires the usage of two separate volumes. One volume will contain the client access point, distribution point, and logon point for the bindery emulation site system, and one volume will contain the client access point, distribution point, and logon point for the NDS site system. This is necessary because the Clicore.exe executable is different for NDS and Bindery, and will be overwritten if both site systems point at the same volume. Configure the bindery emulation site system first. This allows Systems Management Server to select the proper volume for the bindery emulation logon point, and to enter that volume into the site server registry. An NDS logon point can then be created with no fear that the bindery emulation logon point will overwrite it.

• Systems Management Server does not use Novell's IP Stack.

• Alpha computers cannot log on to NetWare (because there is no Novell redirector for that platform).

• Systems Management Server does not communicate with Novell's NDS for Windows NT 1*.x* or 2*.x*.

Installation and Configuration

Redirectors

The network redirector is software that runs on a client computer and is used to communicate with other computers on the network. Below are tables indicating the supported redirectors for use with Systems Management Server 2.0.

Supported Site Server Redirectors

Supported Client Redirectors

Redirector Version Support

intraNetWare Client Connection Model

A significant set of changes has been introduced with the recent versions of the Novell intraNetWare Client for Windows NT. These changes relate to the connection mechanisms that are supported under Windows NT. By default, Windows NT allows separate connections to exist from a single computer to several resources from one or more contexts. For example, a user can log on as DomainA/JoeBrown to a Windows NT domain. A service running on that same Windows NT computer can simultaneously log on to a resource on DOMAINB as DomainB/ServiceAcct.

In intraNetWare Client for Windows NT versions 4.10 and earlier, this connection model is not supported. These versions only allow a single authenticated connection to exist for all users and services on a single Windows NT computer. That means that any computer that has a service or process that requires an authenticated connection to an NDS resource must have a user logged on with sufficient permissions to allow that process to complete successfully. This single connection model can cause potential security risks when there is a disparity between the security requirements for a user and for a service.

Beginning with intraNetWare Client for Windows NT versions 4.11a, two separate connections can exist between a Windows NT computer and an NDS tree. One connection operates in "user" mode (or user context, not to be confused with the term context as it relates to NDS trees), the other in "service" mode (or service context; again, not to be confused with the term context as it relates to NDS trees). In other words, one connection is available to the logged on user; the other connection is available to all services running on the Windows NT computer. Beginning with intraNetWare Client for Windows NT version 4.3, multiple connections can be made in the service context.

intraNetWare Gina.dll

A known issue exists with intraNetWare Client for Windows NT versions 4.11a and 4.3. This is described in Novell SPD #200906 and 197302. This has the potential to affect computers running Windows NT Server that support the Systems Management Server 2.0 site server role. The intraNetWare Client for Windows NT will, under certain conditions, cause a dialog box to appear. When running one of these redirectors, if the SMS_EXECUTIVE service attempts to create or configure a logon point, client access point, or distribution point on an intraNetWare 4*.x* server that is running bindery or bindery emulation, the intraNetWare Client for Windows NT opens a dialog box. This dialog box is "hidden" because the process that attempts to make the connection is a service, not a user application. This behavior appears to cause Systems Management Server to stop responding (hang).

Because this issue exists for intraNetWare Client for Windows NT versions 4.11a and 4.3, Microsoft recommends the use of Microsoft Client Services for NetWare or the Novell intraNetWare Client for Windows NT version 4.5 or later when configuring bindery emulation site systems from a Systems Management Server 2.0 site server. Microsoft also recommends the use of Microsoft Client Services for NetWare or Novell intraNetWare Client for Windows NT version 4.5 or later when configuring NDS site systems from a Systems Management Server 2.0 site server because of the connection model changes that are incorporated with that version.

An additional problem exists with the Novell Clients. On occasion, the redirector can cause the remote procedure call (RPC) to stop functioning on the computer on which it was installed, causing Systems Management Server to stop functioning. This is caused by the Novell logon box (Nwgina.dll). This is a known issue with Novell (SPD# 211572). Microsoft recommends replacing the Novell Gina with the Microsoft Gina until this issue is resolved. To replace the Novell Gina DLL with the Microsoft Gina DLL, edit the registry under the following key:

HKEY LOCAL MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Change the data value GinaDLL from "NWGINA.DLL" to "MSGINA.DLL" (without the quotation marks).

It may not be necessary to restart the computer for Systems Management Server Setup to continue, but it is recommended.

intraNetWare Client 2.5, Bindery Emulation Site Systems, and Windows 95/98 Clients

A Windows 95/98 client must have an existing connection to all bindery emulation logon points, client access points, and distribution points, or Systems Management Server will hang with a visible error message.

How to Get the Latest Redirectors

Novell

Download from https://www.novell.com/download/.

Microsoft

Install the Client Services for NetWare (CSNW) ,and apply the latest Windows NT service pack.

Discovery and Installation Methods and Logon Point Configuration

Discovery methods are the mechanism by which resources (clients) are discovered by Systems Management Server and made available for management. NDS logon points are a combination of a container object (to modify the login script) and a volume object (to place Systems Management Server files, such as installation binaries, discovery data records). Clients can be discovered through the logon discovery method when they run the Systems Management Server section of the logon script. Clients can also be discovered using the Systems Management Server Installation Wizard through implementation of the manual installation method SMSMAN. SMSMAN is run from the logon point.

Additionally, if client installation methods are configured and the client's IPX number falls within the site boundaries, the Systems Management Server client will be installed with all enabled optional components. The appropriate logon installation method can be enabled to allow Systems Management Server client installation upon logon. Manual client installation can be accomplished through the implementation of SMSMAN.

Method	Discovered resource	How initiated	Paired client installation method
NetWare NDS Logon Discovery	Computers	Logon scripts (NetWare NDS)	NetWare NDS Logon Client Installation
NetWare Bindery Logon Discovery	Computers	Logon scripts (NetWare Bindery)	NetWare Bindery Logon Client Installation
Systems Management Server Server Discovery (NetWare Bindery)	NetWare Bindery servers acting as site systems	Automatic	None
Manual Discovery (either bindery or NDS)	Computers	Systems Management Installation Wizard (SMSMan.exe)	Manual Installation

NetWare Clients Resource Discovery Methods

Important: When you enable the NetWare Bindery Logon Discovery or Client Installation method, specified NetWare Bindery servers are assigned the Systems Management Server 2.0 logon point role. The specified or chosen volume is appended to the server, and the server and volume are represented as the site system in the user interface (UI) with whichever roles are assigned to it.

• When you enable the NetWare NDS Logon Discovery or Client Installation method, specified NetWare NDS volumes are assigned the Systems Management Server 2.0 logon point role.

• User and User Group Discovery are not supported for clients running in a Novell–only environment. If clients also participate in a domain and are discovered using Windows Networking Logon Discovery, there is no requirement for resources to have been discovered and installed through Windows Networking Logon Discovery and Installation. The NT User and User Group discovery will discover users and user groups in designated domains without regard to the network operating system type they were installed from. They can use NT User and User Group discovery.

Uninstalling a Logon Point

Clearing the Enable NDS (or NetWare Bindery) Logon Discovery check box under Discovery Methods, or clearing the Enable NDS (or NetWare Bindery) Client Installation check box under Client Installation Methods removes support for the selected method from all specified logon points listed under that method. Note that accounts created during the configuration of the logon point should be removed manually if it is your intent to remove support for the features supported by those accounts.

Security Requirements

Permissions Granted to Client Access Points, Distribution Points, and Logon Points

Systems Management Server 2.0 Windows NT server site systems have permissions set to the local User, Guest, and Admin groups. NetWare site system permissions are not set to these groups, but instead are set as follows.

For NDS client access points and distribution points, permissions will be set to the container object in which the specified volume resides. The administrator might choose to create a volume alias in whichever container object the users reside. For NDS logon points, the permissions are set to the container object specified for script modification. Users that exist in the container objects to which the permissions are set will inherit the needed site system directory rights. This is done because there is no well-known system user groups on NDS such as "Everyone."

For Bindery client access points, distribution points, and logon points, directory permissions will be set to the Everyone group. In the case of NetWare 4*.x* bindery emulation, the NetWare administrator must create the Everyone group prior to creating the site system for permissions to be set.

Platform	Full	Change	Read
Windows NT	Administrator	Read (R), Write (W), Change (X), Delete (D)	Read (R), Change (X),
Bindery	Supervisor (S), Read (R), Write (W), Create (C), Erase (E), Modify (M), FileScan (F) AccessControl (A)	Read (R), Write (W), Create (C), Erase (E), Modify (M), FileScan (F)	Read (R), FileScan (F)
NDS	Supervisor (S), Read (R), Write (W), Create (C), Erase (E), Modify (M), FileScan (F), AccessControl (A)	Read (R), Write (W), Create (C), Erase (E), Modify (M), FileScan (F)	Read (R), FileScan (F)

Comparison of Directory Permissions on Windows NT and NDS

Note: Bindery emulation is considered the same as bindery unless specifically referenced separately.

Directory	NT Admin	NT Guest	NT User	Bindery Everyone	NDS OU
Cap_xxx	Full	Change	Change	Read	Read
Ccr.box	Full	Change	Change	Change	Change
Clicomp.box	Full	Read	Read	Read	Read
Clidata.box	Full	Read	Read	Read	Read
Clifiles.box	Full	Read	Read	Read	Read
Ddr.box	Full	Change	Change	Change	Change
Inv.box	Full	Change	Change	Change	Change
Offerinfo.box	Full	Read	Read	Read	Read
Pkginfo.box	Full	Read	Read	Read	Read
Sinv.box	Full	Change	Change	Change	Change
Statmsgs.box	Full	Change	Change	Change	Change

Client Access Points

Directory	NT Admin	NT Everyone	Bindery Everyone	NDS OU
Smslogon	Full	Read	Read	Read
Config	Full	Read	Read	Read
Ddr.box	Full	Change	Change	Change
Sites	Full	Read	Read	Read
X86.bin	Full	Read	Read	Read

Logon Points

Directory	NT Admin	NT Guest	NT User	Bindery Everyone	NDS OU
Smspkgc$	Full	Read	Read	Read	Read
<package>	Full	Read	Read	Read	Read

Distribution Points

Important: Systems Management Server sets the preceding directory permissions automatically.

Connection Accounts

Connection accounts are those specific accounts that Systems Management Server components use to communicate with NDS or bindery servers to configure client access points, distribution points, and logon points. There are two types of connection accounts: Site System Connection Accounts, and Client Connection Accounts.

Site System Connection Accounts

The site server communicates with other site systems through site system connection accounts. A site system connection account is a Windows NT or NetWare user account that the site services use to communicate with site systems. The type of site system (Windows NT, NetWare 3*.x* or NetWare 4*.x*) determines how Systems Management Server connects from the site server to the site system.

• Systems Management Server only supports one site system connection account to each NDS tree for each Systems Management Server site. It is possible to add multiple NDS Site System connection accounts. However, Systems Management Server will only attempt to use the first NDS site system connection account that matches the tree name specified in the site system configuration screens. Novell generally discourages the use of multiple trees in a single organization; however, if this configuration exists, Systems Management Server allows a single site system connection account for each tree. When creating an NDS User account that will be used as the site system connection account, you must assign appropriate permissions to the user account by means of the additional NWAdmin or NETADMIN utilities provided by NetWare. For more information about using these Novell applications, refer to the documentation that accompanies the Novell product.

  You can create an NDS User account that has the Security Equal property set to the Admin user of your tree. This is the simplest method, as the Admin user has full permissions to all objects of the NDS tree. If this is not feasible or is not desired for security reasons, you can assign the individual permissions required of a site system connection account:

  1. The account specified must be a trustee, and have RWCEMFA permissions to the root directory on volumes that are to be client access points, logon points, or distribution points.

  2. The account specified must have Read and Write permissions to the Login Script property of all container objects specified in NetWare NDS Client Logon Installation and NetWare NDS Client Logon Discovery. This security configuration is not necessary if you do not choose to have Systems Management Server automatically modify any container logon scripts.

  3. The account specified must be able to assign file and directory permissions to the parent container object of each volume that is to be a client access point and a distribution point.

  4. The account specified must be able to assign file and directory permissions to the volume specified for each logon point and for each container object specified as a logon point.

  The following figures illustrate how a site server connection can be configured. Note the account has rights to the volume that is to be configured, and rights to the OU where the user's login scripts will reside.

  

  

Note: When you run a Systems Management Server client on Microsoft® Windows NT® 3.51, you must be logged on to Windows NT and NDS with a single account that has whatever rights the connection account requires. This is due to a limitation of the Novell redirector.

NetWare NDS Site Systems

If the site system is a NetWare NDS volume, Systems Management Server attempts to connect to it using the following methods in the order listed below:

1. If a service connection to the NDS system exists, Systems Management Server attempts to use the connection. The Systems Management Server service ignores any user connections and only uses an existing service connection (for example, a connection established by another Systems Management Server service). This connection could also exist as a result of other non-Systems Management Server services running.

2. If the existing connection's credentials are insufficient (for example, if the account does not have permission to browse the root directory of the volume acting as the site system), the Systems Management Server service attempts to use any existing NDS site system connection accounts.

3. If no connection to the NDS system exists, the Systems Management Server service attempts to connect through a NetWare NDS site system connection account. If there are multiple NDS site system connection accounts, and if the permissions of one account are insufficient, the Systems Management Server service will not attempt to connect using the other accounts.

4. If the NDS Site System connection account has a tree name that does not match the tree name specified for the site system that is being created or updated, Systems Management Server will attempt to use the next site system connection account in the list of NDS site system connection accounts.

5. If all of these attempts fail, Systems Management Server makes no further connection attempts, and the connection process fails. View the Status Manager for more information on the connection failure.

NetWare Bindery Site Systems

If the site system is a NetWare bindery system, Systems Management Server attempts to connect to it using the following methods, in order:

1. If a service connection to the bindery system exists, Systems Management Server attempts to use the connection. The Systems Management Server service ignores any user connections and uses only an existing service connection (for example, a connection established by another Systems Management Server service).

2. If the account credentials are insufficient (for example, if the account does not have Supervisor permissions to the bindery server), the Systems Management Server service attempts to use any existing bindery site system connection accounts.

3. If a connection to the bindery system does not exist or if the existing connection's account has insufficient permissions, the Systems Management Server service attempts to connect through a NetWare bindery site system connection account. If there are multiple bindery site system connection accounts, and if the permissions of one account are insufficient, the Systems Management Server service attempts to connect through the other accounts.

4. If the attempts to connect using the site system connection accounts fail, or if there are no site system connection accounts, the Systems Management Server service attempts to connect through the Systems Management Server service account.

5. If all of these attempts fail, Systems Management Server makes no further connection attempts, and the connection process fails. View the Status Manager for more information on the connection failure.

Client Connection Accounts

A Windows NT client connection account is a Windows NT or NetWare user account that Systems Management Server client services can use to contact client access points and distribution points. The type of site system determines how Systems Management Server attempts to connect from the client to the site system.

NetWare NDS Site Systems

If the client is running Windows NT, and if the site system is a NetWare NDS system, Systems Management Server attempts to connect to the site system using the following methods, in the order listed:

1. If a service connection to the NDS system exists, Systems Management Server attempts to use the connection.

2. If a connection to the NDS system does not exist or if the existing connection's account has insufficient permissions, the Systems Management Server client service attempts to connect through the NetWare NDS client connection accounts. If more than one of these accounts exists, and if the permissions of one account are insufficient, Systems Management Server attempts to connect through the other accounts.

3. If the attempts to connect with the NetWare NDS client connection accounts fail, Systems Management Server attempts to connect using the SMSCliToknAcct& account.

4. If these attempts fail, Systems Management Server makes no further connection attempts, and the connection process fails.

If the client is running an operating system other than Windows NT, Systems Management Server attempts to connect to the site system through the account of the user who is currently logged on. If this attempt fails, Systems Management Server makes no further connection attempts, and the connection process fails.

NetWare Bindery Site Systems

If the client is running Windows NT, and if the site system is a NetWare bindery system, Systems Management Server attempts to connect using the following methods:

1. If a service connection to the bindery system exists, Systems Management Server attempts to use that connection.

2. If there is no service connection to the bindery system, or if the existing connection's account has insufficient permissions, the Systems Management Server client service attempts to connect through the NetWare bindery client connection accounts. If more than one of these accounts exists, and if the permissions of one account are insufficient, Systems Management Server attempts to connect through the other accounts.

3. If the attempts to connect through the NetWare bindery client connection accounts fail, Systems Management Server attempts to connect to the account that the Systems Management Server client service runs under. This account is created automatically when the Systems Management Server client software is installed on the client.

4. If all of these attempts fail, Systems Management Server makes no further connection attempts, and the connection process fails.

If the client is running an operating system other than Windows NT, Systems Management Server attempts to connect to the site system using the account of the user who is currently logged on. If this attempt fails, Systems Management Server makes no further connection attempts, and the connection process fails.

Appendix A: NetWare Logon Script Examples

Automatically Configured Logon Script Example

Logon Server Manager adds the following lines to the container script. You cannot remove any of these lines. If you do, the Systems Management Server client will not function properly.

REM Microsoft Systems Management Server (start)
REM Systems Management Server Build XXX
IF "%OS." == "WINNT." THEN GOTO SMS_32BIT
IF "%OS." == "WIN95." THEN GOTO SMS_32BIT
IF "%OS." == "MSDOS." THEN
  IF "%OS_VERSION." == "V7.00." THEN GOTO SMS_32BIT
END
GOTO SMS_END
SMS_32BIT:
IF "%<SMS_LOCAL_DIR>." <> "." THEN
  #%<SMS_LOCAL_DIR>MS\SMS\CORE\BIN\SMSNDS1.EXE -D -N
  IF "%ERROR_LEVEL" <> "2" THEN GOTO SMS_END
END
IF "%<SMS_LOCAL_DIR_USER>." <> "." THEN
  #%<SMS_LOCAL_DIR_USER>MS\SMS\CORE\BIN\SMSNDS1.EXE -D -N
  IF "%ERROR_LEVEL" <> "2" THEN GOTO SMS_END
END
# *****PATH_ON_SERVER***** \ *****SMSLOGON***** \NETLOGON\SMSNDS1.EXE
SMS_END:
REM Microsoft Systems Management Server (end)

Notes:

• Administrators must not edit between the (start) and (end) sections.

• Underlined sections will be updated by Systems Management Server at installation.

Appendix B: Systems Management Server 2.0 NDS Components

The following components directly provide NDS logon point configuration support, and run on the site server as threads of SMSEXEC.

NAME: ND_LOGON_MANAGER

DLL: (Nd_logon.dll)

RESPONSIBILITIES:

Responsible for managing the NetWare NDS logon points.
Copies files to logon points.
Configures and manages logon scripts settings.
Cooperates with other Systems Management Server sites that may be sharing a logon point.

NAME: ND_LOGON_DISCOVERY_MANAGER

DLL: (Ndlgdscm.dll)

RESPONSIBILITIES:

Interprets changes made to NDS logon discovery settings and passes them to Logon Server Manager. Logon Discovery Manager also retrieves Discovery Data Records (DDRs) from logon points.

NAME: ND_LOGON_INSTALLATION_MANAGER

DLL: (Ndlginst.dll)

RESPONSIBILITIES:

Interprets changes made to NDS logon client Setup settings, and passes them to Logon Server Manager.

NAME: ND_LOGON_DISCOVERY_MANAGER

PATRON CONFIG FILE (PCF):

Location after Systems Management Server Setup is complete:

\\SMS_site_server\SMS_installation_directory\Inboxes\Nd_logon.box\Ndlgdsc.pcf

RESPONSIBILITIES:

This file specifies Logon Discovery configuration information. NDS Logon Discovery Manager writes and updates this file.

NAME: ND_LOGON_INSTALLATION_MANAGER

PATRON CONFIG FILE (PCF):

Location after Systems Management Server Setup is complete:

\\SMS_site_server\SMS_installation_directory\Inboxes\Nd_logon.box\Ndlginst.pcf

RESPONSIBILITIES:

This file specifies Logon Client Setup configuration information. NDS Logon Installation Manager writes and updates this file.

NAME: ND_LOGON_MANAGER

PATRON CONFIG FILE (PCF):

Location after Systems Management Server Setup is complete:

\\SMS_site_server\SMS_installation_directory\Data\Nd_Logon\Nd_logon.pcf

RESPONSIBILITIES:

This file specifies specific static logon point configuration information. NDS Logon Server Manager manages this file.

Other Important Files

LOGON CONFIG FILE (LCF):

LOCATION: \\Site_System\SMSlogon\Config\Sitecode_CFG.LCF

RESPONSIBILITIES:

One unique LCF exists on each logon point for every site that is sharing the logon point. The LCF is basically a compilation of a site's NDS Patron Config files.

MASTER CONFIG FILE (Master.mcf):

LOCATION: \\Site_System\SMSlogon\Config\Master.mcf

RESPONSIBILITIES:

Only one Master Config file (MCF) exists on each NDS logon point. This file is a compilation of all a logon point's LCFs. The MCF is used as a master information reference for configuring an NDS logon point.

SITELIST FILE:

LOCATION: \\Site_System\SMSlogon\Config\Sitelist.lst

RESPONSIBILITIES:

This file contains specific information about the Systems Management Server sites managing the logon point.

Appendix C: Setting Up Novell NDS Integration With Systems Management Server

For the example below, please refer to the NDS Tree and Systems Management Server Site Hierarchy below.

There are five main steps in setting up a Systems Management Server 2.0 Site that can configure an Novell NDS Site System.

1. Add the Novell Client redirector to your Systems Management Server 2.0 Site System.

2. Set up the connection accounts.

3. Turn on the logon points.

4. Add the site system.

5. Turn on Discovery (optional).

Sample Systems Management Server Site Hierarchy.

(Note: You do not have to configure your site in this way.)

The following figure shows how our NDS environment was configured.

Sample Novell NDS Tree

Add the Novell Client to Your Systems Management Server 2.0 Site System

Set up the Novell Client on the site server. Follow the instructions provided with the Novell Client.

Note: For bindery emulation, you must use the Novell intraNetWare client 4.5 or higher. For NDS and Bindery modes, you can use either the Novell 4.3 or the Novell intraNetWare 4.5 Client. See the Redirectors section for more information.

1. In the Systems Management Server Administrator program, navigate to the Discovery Methods item underneath Site Settings.

   

2. Double-click NetWare NDS Logon Discovery to open the properties.

   

3. On the General tab, click to select the Enable NetWare NDS Logon Discovery check box.

4. Click the New Logon Point button to add the server name that will do the discovery.

5. Type the name of the server you want to configure.

   

   

6. Click OK. Repeat steps 4, 5, and 6 to create an additional logon point (if necessary).

7. When you are done, the logon points should look similar to those in the following dialog box.

   

8. Click the Logon Settings tab.

   

9. Make sure that Modify login scripts is selected.

10. On the Polling Schedule tab, you can modify the polling schedule. The polling is done to collect the data discover records from the Novell server because the Novell server has no agent on it to tell the Systems Management Server site that new records are waiting.

    

11. Click OK.

12. Repeat steps 1 through 6 for any other servers you want to do Discovery with.

Set Up the Connection Accounts

Site System Connection Account

1. Navigate to the Site system item under Connection Accounts as illustrated in the following figure. Right-click in the details pane, and click New, then Netware NDS. Select Set. Type the information provided from your NDS tree. Click OK.

   

   The following figure shows what the finished account looks like.

   

Client Connection Account

1. In the Systems Management Server Administrator program, navigate to the Client item under Connection Accounts.

   

2. Right-click in the right pane, click New, click NetWare NDS, and then click Set.

3. Type in the information provided from your NetWare NDS Tree.

   

4. Click OK. The following figure shows what the finished account looks like.

   

Turn on NDS Logon Point

1. In the Systems Management Server Administrator program, navigate to the Client Installation Methods object as shown in the following figure.

   

2. In the right pane, right-click the NetWare NDS Logon Client Installation item, and then select Properties.

   

3. On the General tab, click the Add Tool (yellow star) button to add a logon point.

   

4. Type in the information provided from your NetWare NDS Tree.

5. Click OK.

   

6. Repeat Steps 1,2, and 3 under "Setting up Novell NDS Integration with Systems Management Server" for any other NDS logon points you may be creating for your site.

   Note: If you are creating multiple logon points on a single server, please see the "Supported Platforms for Site System Roles" section under "Installation and Configuration."

7. Click OK.

   

8. Click to select the Enable NetWare NDS Logon Client Installation check box.

9. When completed, the General tab on your NetWare NDS Logon Client Installation Properties dialog box should appear similar to the one above.

10. Click OK.

11. Click the Logon Settings tab, and modify it as necessary. If you want Systems Management Server to modify your clients' logon scripts by adding smsls to the script, click to select Modify login scripts.

    

12. Click OK.

Add the Site System

1. In the Systems Management Server Administrator program, navigate to the Site System item under Site Settings.

   

2. Right-click in the right pane, click New, and then click NetWare NDS Volume to open the Site System Properties dialog box.

   

3. On the General tab, click Set.

4. Type in the information provided from your NetWare NDS Tree.

   

5. Click OK.

6. Click the Client Access Point tab.

   

7. If you want this NDS volume to be a client access point, click to select the Use this Site System as a Client Access Point check box.

8. Click the Distribution Point tab.

   

9. If you want this NDS volume to be a client access point, click to select the Use this Site System as a Client Access Point check box.

10. Click OK.

11. Repeat Steps 1 through 9 under "Add the Site System" for any other NDS site systems you create.

    The following is a completed screen shot of what your site systems should look like.

    

Appendix D: Setting Up Novell Bindery Integration with Systems Management Server

For the example below, please refer to the following Bindery Syscon screen shots and Systems Management Server Site Hierarchy.

There are four main steps in setting up a Systems Management Server 2.0 Site that communicates with a Novell Bindery Server.

1. Add the Novell client to your Systems Management Server 2.0 Site System.

   -or-

   Set up the Connection Accounts.

2. Turn on the client logon points.

3. Add the site system.

4. Turn on Discovery (optional).

   

   Sample environment.

   (Note: You do not have to configure your site in this way.)

   

   Sample NetWare Bindery Users

   

   Sample NetWare Bindery Logon Script (Prior to Systems Management Server)

   

   Sample NetWare Bindery Logon Script (after Systems Management Server)

Add the Novell Client to your Systems Management Server 2.0 Site System

Set up the Novell client redirector on the site server. Follow the instructions provided by Novell with the Novell client redirector.

Note: For bindery servers, you can use the Novell intraNetWare client 4.3 or 4.5 or Gateway Services for NetWare. For bindery emulation servers, you can use the Novell intraNetWare client 4.5 or Gateway Services for NetWare.

Set Up the Connection Accounts

Site System Connection Account

1. In the Systems Management Server Administrator program, navigate to the Site System item under Connection Accounts.

   

2. Right-click in the details pane, click New, click NetWare Bindery, and then click Set.

   

3. In the User Name text box, type the information provided from your NetWare bindery server.

4. Click OK. The picture below shows what your completed Bindery Server Connection Account may look like.

   

Discovery

1. In the Systems Management Server Administrator program, navigate to the Discovery Methods item underneath Site Settings.

   

2. Double-click NetWare Bindery Logon Discovery, in the right pane.

   

3. Click to select the Enable NetWare Bindery Logon Discovery check box.

   Note: The Keep logon point lists for discovery and installation synchronized is selected by default. If you change this, you are prompted with a dialog box that will tell you that action will affect the Client Installation method as well.

4. Click the New Logon Point icon (yellow star) to add the server name as a logon point in order to perform discovery.

   

5. In the Server name text box, type the server name.

6. Click OK.

   When complete, the Logon points list should appear similar to the following figure.

   

7. Click the Logon Settings tab.

   

8. Make sure Modify login scripts is selected.

9. If necessary, on the Polling Schedule tab, modify the DDR polling schedule. DDR polling is done to collect the data discovery records from the Novell server because the Novell server has no agent on it to tell Systems Management Server that a new record has been created.

   

10. Click OK.

11. Repeat steps 1 through 6 for any other servers you want to perform Discovery with.

Turn on NetWare Bindery Logon Point

1. In the Systems Manager Server Administrator program, navigate to the Client Installation Methods item.

   

2. In the right pane, right-click the NetWare Bindery Logon Client Installation item, and select Properties.

   

3. On the General tab, click the New Logon Point icon to add your logon point.

4. In the Server name text box, type in the information provided for your NetWare Bindery Server.

   

5. Click OK.

6. Repeat Steps 1, 2, and 3 under "Setting up Bindery Integration with Systems Management Server," for any other bindery logon points you may be creating for your site.

7. Click OK.

   

8. When completed, your NetWare Bindery Logon Client Installation Properties dialog box should look like the one above.

9. Click OK.

10. Modify the Logon Settings tab as necessary. More than likely, you will want to enable Modify login scripts.

    

11. Click OK.

Add the Site System

1. In the Systems Management Server Administrator program, navigate to the Site System item under Site Settings.

   

2. Right-click in the right pane, click New, and then click NetWare Bindery to open the Site System Properties dialog box.

   

3. On the General tab, click Set.

4. In the Name text box, type in the information for your bindery server and volume.

   

5. Click OK. Click the Client Access Point tab.

   

6. If you want the Bindery server volume to be a client access point, click to select the Use this Site System as a Client Access Point check box. Click the Distribution Point tab.

   

7. If you want this Bindery Volume to be a distribution point, click to select the Use this Site System as a Distribution Point check box.

8. Click OK.

9. Repeat steps 1 through 9 under "Add the Site System? for any other bindery site systems you may be creating.

Appendix E: Troubleshooting

Discovery Methods

Q: When I turn on Discovery Methods for NDS, what can I check to make sure it is set up correctly?

1. Check the NetWare NDS Logon Discovery Properties page under Discovery Methods, and make sure that the syntax of the container and volume that you intend to discover is correct. You can check what syntax you specified by going to the Discovery Methods option underneath the Site Settings option, and double-clicking the type of discovery you choose (Bindery or NDS). This dialog box will list the container and volumes you have chosen as discovery points. You must follow typeless fully distinguished notation conventions when defining the volume object name and container object for your NDS Site System. Systems Management Server does not support typeful notation.

2. Make sure the Systems Management Server Logon directory has been created on the volume you specified when setting up your Client Installation Method, and that there is a Ddr.box directory located underneath the SMSLogon directory. You can check which volume you specified for your SMSLogon directory by going to the Client Installation Method option underneath your Site Setting option, and double-clicking the type of logon you chose (Bindery or NDS). This dialog box will list the volumes you have chosen as logon points.

3. Make sure that the user or service account (the logged-on user on Windows 95/98, or the Client Connect Account on Windows NT) that writes to the Ddr.box directory is able to do so. Whichever account this may be needs Read and Write access to the directory.

4. Ensure that you have an NDS Site System Connection account, and that the specified account is a trustee of the NDS volume site system with full permissions (SRWCEMFA) to the root of the volume. The Supervisor (S) file and directory permission are optional. Try to connect manually using that account. Ensure no restrictions occur when you connect.

5. When you try to troubleshoot further than the Status Manager, you can use the log files that Systems Management Server can create for you. Note, however, that some performance degradation will occur. Navigate to the Site Database, Tools, Systems Management Server Service Manager item. Right-click the Service Manager, and then click Start. After the Service Manager starts, go to the service below that pertains to the version of NetWare you are running and right-click the component you want to log. Then turn on the Logging option. This will place log files in your Sms\Logs directory.

   Here are the default log file names for two Systems Management Server components.

   For bindery: SMS_NW_Logon_Discovery_Manager - Nwlgdsc.log

   For NDS: SMS_ND_Logon_Discovery_Manager - Ndlgdsc.log

Logon Points

Q: When I set up a logon point, what can I check to make sure it is set up correctly?

1. Check the NetWare NDS Logon Client Installation Properties page under Client Installation Methods, and make sure that the syntax you typed for your container and volume are correct. You can check what syntax you specified by going to the Client Installation Method item underneath your Site Setting, and double-clicking the type of logon you choose (bindery or NDS). The dialog box will list the container and volumes you have chosen as logon points.

   Note: You must follow typeless notation fully distinguished conventions when defining the volume object name for your NDS site system. Systems Management Server does not support typeful notation.

2. Check the Component Status Summarizer, then Site System Status in the Systems Management Server Administrator program, and make sure the logon point is green. This will verify that the site system does not have any critical failures. If it is yellow or red, look at the messages for this component by right-clicking the site name underneath Site System Status, and then choosing Show Messages – Errors.

3. Check to see if the SMSLogon directory has been created on the volume you specified when setting up your Client Installation Method. You can check which volume you specified by going to the Client Installation Method underneath your Site setting, and double-clicking the type of logon you chose (bindery or NDS). This dialog box will list the volumes you have chosen as logon points.

4. Ensure that you have an NDS Site System Connection account, and that the specified account is a trustee of the NDS volume site system with full permissions (SRWCEMFA) to the root of the volume. The Supervisor (S) file and directory permission are optional. Attempt to connect manually.

5. From the Systems Management Server site server, log on as the Systems Management Server Site System Connection account, and verify that you have Connectivity and Read/Write permissions to the location in which the logon point was to be created.

6. If another Windows NT service (that is, any application that uses a service to connect to NDS) has opened a connection to the site system that you have targeted as a logon point, Systems Management Server will attempt to use that connection before trying the site system connection account. If your logon point does not successfully get created with the existing connection that was established with another Windows NT service, you may need to stop the other Windows NT service so that Systems Management Server can use the site system connection account you configured.

7. When trying to troubleshoot further than the Status Manager, you can use the log files that Systems Management Server can create for you. Note, however, that you will take a performance hit for turning this on. Go to the Site Database, Tools, SMS Service Manager in the Systems Management Server Administrator program, right-click the Service Manager, and click Start. After the Service Manager starts, go to the service below that pertains to the version of NetWare you are running, and right-click the component you wish to log. Turn on the Logging option. This will place log files in your C:\Sms\Logs directory.

   For Bindery: SMS_NW_LOGON_SERVER_MANAGER - NW_Logon.log

   For NDS: SMS_ND_LOGON_SERVER_MANAGER - ND_Logon.log

Connection Accounts

When creating connection accounts, Systems Management Server checks the syntax to see if it is correct when you click OK. However, it does not check at this point whether the connection account is valid (for example, you could enter .x.y, and the connection account could really be valid only if typed .y.x). Systems Management Server checks the account for validation after the account has been entered, and the process for creating a client access point or logon point is started. Systems Management Server then checks to see if it can read a file from the drive on which it is going to create the client access point or logon point. If this succeeds, it tries to write the client access point.

Note: This is where a common error occurs because the connection account could read a file successfully, but does not have rights to configure the client access point on that volume.

Q: What can I check to make sure the connection accounts work correctly?

After entering the information, there is nothing to check. When Systems Management Server tries to use the accounts to create a client access point and Systems Management Server Logon directory, it will try an existing service connection (see the "client access point" or "logon point" section). If it fails with an existing connection, then it will check the site system connection account.

1. Try manually connecting as the account. Ensure no restrictions exist on the account such as lockout, maximum number of connections, and so on.

2. Check the site status to see if the connection accounts have failed when Systems Management Server is trying to create the client access point or the logon point. If you see an error, one way to check the connection account is to log on as the connection account you set up, and check to see if you can access the site system you want to configure.

Client Access Points

Q: When I set up a client access point, what can I check to make sure it is set up correctly?

Steps to see if the client access point is set up correctly.

1. Check the properties of the NDS Site System page under Site System, and make sure that the syntax is correct for the NDS volume. For examples of correct syntax, please see Appendix C. You must follow typeless fully distinguished notation conventions when defining the volume object name for your NDS Site System. Systems Management Server does not support typeful notation.

2. Check the site system status and make sure the client access point is green. If not, follow the suggestions in the status message.

3. Check to see if the CAP_SiteCode directory has been created on the NDS volume specified in the site systems node.

4. Re-enter the password in case of a typo.

5. Ensure that you have an NDS Site System connection account, and that the account that is specified is a trustee of the NDS volume site system with full permissions (SRWCEMFA) to the root of the volume. The Supervisor (S) file and directory permission are optional.

6. Ensure that the NDS Site System connection account has sufficient permissions to assign file and directory permissions to the volume object's parent container. The Site System connection account will attempt to assign Read/Write and Read Only permissions for client access point directories to the volume object's parent container as part of the client access point setup routine.

7. If another Windows NT service (that is, any application that uses a service to connect to NDS) has opened a connection to the site system that you have targeted as a logon point, Systems Management Server will attempt to use that connection before trying the site system connection account. If your logon point does not successfully get created with the existing connection that was established with another Windows NT service, you may need to stop the other Windows NT service so that Systems Management Server can use the site system connection account you configured.

8. When trying to troubleshoot further than the Status Manager, you can use the log files that Systems Management Server can create for you. Note, however, that you will take a performance hit for turning this on. Go to the Site Database, Tools, SMS Service Manager, right-click the Service Manager, and then click Start. After the Service Manager starts, go to the service below that pertains to the version of NetWare you are running, and right-click the component in the right pane. Then turn on the Logging option. This will place log files in your C:\Sms\Logs directory.

   This example shows the default log file name for the Inbox manager component:

   Sms_inbox_manager - Inboxmgr.log

Q: I'm on a bindery server, and my client access point is corrupted. What should I do?

1. Check to be sure there is no data in either your Ddr.box directory or your Ccr.box directory.

2. If they are empty, delete the entire client access point directory (for example, "CAP_SiteCode," where SiteCode is your Systems Management Server site name). It will be re-created the next time the Bindery Inbox Manager Agent runs again.

Q: I'm getting a Novell logon dialog box on my Windows NT client that opens, and the user account is listed as SMSCliToknAcct&.

This indicates that the Systems Management Server client components cannot connect to the client access point.

1. Examine your site system connection accounts, and check to be sure that you have specified a client connection account.

2. If the account exists, ensure that its name is spelled correctly, and that it has the permissions necessary to the client access point.

Known Issues and Concerns

This section discusses known issues and concerns when integrating Systems Management Server 2.0 with Novell NetWare.

1. Systems Management Server site server set up to configure both NDS and bindery site systems must have the Novell 4.5 redirector installed. When installing the redirector, it must be configured to support NDS logon (note that this is the default configuration). If you are only configuring bindery site systems, you can run a custom setup of the redirector and select the Bindery only logon option. If the redirector is configured to support NDS logon, then Systems Management Server, NDS, and bindery server components will be able to configure and manage their site systems by using existing NDS and bindery site system connections. New connections can only be made with connection accounts specified to the component. Systems Management Server bindery server components can only create a connection to the NetWare server using bindery connection accounts, and NDS components can only create connections using NDS accounts.

   In the scenario where both bindery and NDS site systems are configured by the same site server on the same NetWare server, both a bindery and NDS site system connection account must exist. Both accounts need adequate permissions to the site system volumes. Both need to have Write permissions to the NDS logon point container object properties. Both need to be Supervisor equivalent in the bindery context for bindery script updating capability.

2. It is recommended that users visually check to see that the directory permissions on NDS client access points, logon points, and distribution points are set properly.

3. If more than one NetWare Directory Service (NDS) site system connection account exists in the same NDS tree for the purpose of managing multiple NDS site systems within that tree, each account must be restricted from having file-level permissions to any site system volumes other than the one it is to manage. If a connection account has even File Scan permissions to a site system volume other than its own, there is a risk that the other site system will not be created or updated.

4. When Slownet.exe is called from the NetWare logon point, script will not detect net speed but instead will check to see if the client has a Remote Access Service (RAS) connection. If RAS is being used, the client will not proceed with the bootstrap process. If RAS is not detected, the process will continue.

5. NetWare clients using Shiva LAN Rover or Novell NetWare Connect for remote access will not be detected as RAS clients; therefore, the Systems Management Server bootstrap process will continue. Unless remote NetWare clients are detected as running as RAS clients, Systems Management Server will perform as if the link is fast.

6. Manually changing the parameter following Slownet.exe in the Smsls.scr will have no effect. Any value entered for this parameter will return 0, which triggers the Check_RAS routine.

   From Slownet.cpp:

   // Slownet <remote path> (<enter required speed or 0 for "RAS Check only">) (/v)

7. For this release, NetWare bindery and NDS logon points cannot be shared by multiple Systems Management Server sites.