Search the Catalog
Desktop Management with Novell ZENworks

Desktop Management with Novell ZENworks

By Gerald Foster
1st Edition April 2000
1-56592-711-7, Order Number: 7117
286 pages, $29.95

Chapter 3
The NetWare Clients and Related Components

The NetWare clients for Windows have been designed to allow the user to connect to and use NetWare services from workstations running Windows 3.x, Window 95 or 98, and Windows NT or 2000. The clients will authenticate to a Bindery or NDS-based NetWare server and include components which, behind the scenes, fully integrate NetWare functionality into the Windows operating system, allowing users to manipulate NetWare resources transparently. This high level of integration allows for seamless inclusion of graphical user interface (GUI)-based mechanisms to support all the functionality that was available under DOS. As well as the inclusion of this functionality there is backward compatible support for NetWare-aware DOS applications. Novell has gone to a great deal of trouble to ensure that Microsoft desktop operating systems, which are the choice for most of the world's users, can be fully integrated into the Novell network operating environment.

In this chapter, I look at how to configure the client and Workstation Manager in detail. I also review how the client integrates into the operating system by analyzing the system architecture of the Windows 32-bit operating systems. This sort of detail is particularly important if you are trying to debug a problem and you need to understand how it actually works. If you find the depth of some of the material in this chapter daunting, don't worry. The architectural detail of the clients is included for debugging purposes. You will need to understand how the client should be configured and this detail should not be such heavy going.

Client Configuration

The NetWare client can be configured in a variety of ways. You may wish to configure through the Network Control Panel, through the Novell Client Installation Manager NCIMAN.EXE, or via the NetWare Client Configuration Policy. In each of these cases, the configuration details and the associated issues are the same.

The client configuration interface consists of a dialog containing several tabbed pages where configuration data is displayed. Some of these fields will have suggested values that can either be kept or modified, and some will need to have values entered by you. The default values for most settings are altogether adequate for the most part, and may never need to be changed, but are covered in detail later in this chapter. After the client has been installed and configured and the PC has rebooted, enter a user ID and password, then click the Advanced button to enter the NDS tree required and the context of the ID. Through the Pages list under the Advanced button, you can also configure the client to run login scripts, set login environment variables, and prepare a host of other settings.

If you have not used the client before, then set the characteristics of your NetWare environment through the Advanced button and get a feel for how it works. Enter the NDS Tree or Server, your user ID and password, and the context of your user ID. You should carefully review all of the client settings at some stage during the service development to ensure you have maximized the performance and security of your network service.

Client

From the Client tab you are able to define several important settings including the tree or server to log in to and the default context. The Windows NT/2000 client configuration page is shown in Figure 3-1. The configuration screens for Windows 95/98 and Windows NT/2000 clients are different in appearance, but contain the same configuration settings.

Figure 3-1. Windows NT client configuration

 

One of the settings, which initially seems quite straightforward, is the first network drive. This setting requires you to do some planning to ensure that the service will function in the way the user expects and to ensure that you have capacity for future services.

The first network drive setting allows you to define which drives to reserve in your organization for local devices. The problem with local drives is that the number of local devices will vary depending on the makeup of the workstation. If the first network drive is defined as the first to be available after all of the local drives, then this would vary from machine to machine, making it very difficult to predict where the network services are connected. The best way to define the first network drive value is to review the workstations in your organization and select a drive that will not conflict with any of them.

TIP:  

It is worth taking the time to develop a plan for your workstation drive mappings. You will need to take into account all of your current requirements, your users' requirements, and what you may require in the future. This may seem like crystal ball gazing, but if you keep as many resources up your sleeve as you can, it may pay off next year.

It is generally a good policy to plan how drives will be used in your organization. Users will soon start to use services connected randomly to whichever drive they happen to select next. This will be okay until you decide to set up a new service and find that the users have mapped all the available drives, leaving you without a place to mount the new service. Therefore, it is important to have a plan dictating how the drives will be mapped in your organization. It is possible to restrict which drives can be mapped by using policies that are discussed in detail in Chapter 4, ZENworks Policy Packages. Table 3-1 outlines an example drive-mapping plan.

Table 3-1: Example Drive-Mapping Plan

Drive Letter

Description

A:

Local floppy disk drive

B:

Local floppy disk drive

C:

Local hard disk

D:

Reserved for local device

E:

Reserved for local device

F:

Home directory

G:

Group file share

H:

Networked applications

I:

Reserved for future networked applications

J:

Reserved for future networked applications

K: to O:

User definable drives

P: to S:

Reserved for networked CD-ROMs

T: to Y:

Reserved for future

Z:

Mapped to sys/public volume

From this example you can see that the local drives are planned along with the immediately obvious network services. There is an allocation of five drives for networked CD-ROM services and a provision for the users to map five of their own drives and also a reservation for future services. This plan will become a cornerstone for your network service.

Location Profiles

Workstations are generally installed in an office and that is where they stay. Location Profiles allow the user to choose which location they are currently in. This makes Location Profiles a bit confusing, because you may well conclude that the workstation is always in the same location. So why allow the user to choose a location? These profiles are useful for workstations that aren't stationary, such as portable computers. Users with portables can potentially plug their machine in anywhere and then find that they cannot log in or cannot get access to a service. This is probably because their client configuration details are inappropriate to their location.

The Location Profiles page is used by the Network Administrator to preconfigure the client for each location regularly visited by the user. When the user arrives at the remote location, he plugs in his workstation, selects the location from the client Login Dialog Box, logs in, and connects to network services successfully.

Suppose you have a user who is based in London and who regularly visits offices in Paris and New York. You may choose to add location profiles for the three office locations. If you mimic the application drive on all your main site servers and you make the connection to that drive during login, you will probably not want this connection to be made to his home site (London) but to the site he is visiting (Paris). This means that the primary application drive (drive H:) is connected to one of the Paris servers and not the London server, because you don't want the application to be launched through the WAN link. On the other hand, you don't want all the network redirected drives to be at the local site (Paris), because the user's personal files will probably be located in London; so drive F: (the user's home directory) will need to be connected to one of the London servers. You may also wish to connect a local printer, as the user will probably not want to print in London when connected in Paris.

Contextless Login

In NDS terms, a context is the path to the user object in the NDS tree. Contextless login allows users to enter their user ID and password without having to know their context and is available from NetWare 5 servers that have catalog services running. In an environment where users share workstations and where there are a large number of users whose objects are installed in different containers, the context for the user will be different. This can cause confusion amongst the users because they not only have to remember their username and password, but also their context. When contextless login is enabled and catalog services is running on the server, the user will not have to enter his context; it will be provided for him automatically when he logs in.

Advanced Login

The Advanced Login page allows you to configure how the client login box will appear to the user. These settings will allow the user more flexibility to control how and where he logs in. If your users are able to deal with these settings and your requirement is that they have this much flexibility, then you will need to make this setting available. There can, however, be problems with allowing a user this much flexibility. If the user is not expert or tends to want to explore, he could decide to fiddle with the settings, disable the login script, or simply stop the client from working. It is probably a good idea to disallow access to the Advanced button in the Login Dialog Box for most, if not all, your users. If you wish to restrict the user as much as possible and only wish him to enter a username and password, then check all of the boxes shown in the Advanced Login page.

WARNING:  

Allowing users to select their own settings during login could cause all sorts of problems if they decide to disable the login script or change any settings. It is better to set this up for them and disallow them from this area by hiding the Advanced button.

Advanced Settings

The Advanced menu is part of the client configuration dialog and is really for advanced users; that is to say, it is not for end users, but for you. The settings under this menu all have default values which should work in your environment. It is worth looking through these settings to take a view on what you may require for you service, as shown in Figure 3-2. Some will be obvious, but some will have values that should not be changed unless you know what you are doing.

Figure 3-2. Windows NT advanced settings

 

The settings can vary enormously from setting environment variables to tweaking the way packets are delivered through your network. The settings include restrictions for the presentation of certain client functions on the desktop.

TIP:  

Don't be tempted to interfere with the settings that affect packet delivery through your network unless you are sure you understand the issues. Some of the settings are quite straightforward and some really are advanced. If possible, don't allow your users near this control panel.

The following list describes the advanced settings:

Alert Beep
When pop-up messages are received they can alert the user with a beep. This setting will allow the beep to be on or off and is available under Windows 95/98 only.

Auto Reconnect
The auto reconnect feature allows a client to re-establish connections to services after that service has become unavailable because of a restart or network fault. Under Windows NT/2000, the value can be either off or on, whereas under Windows 95/98, the value can be an integer from zero to five as follows:

0
No Auto Reconnect, equivalent to off

1
Connections to devices such as redirected drives and printers will be restored

2
All of item 1 plus the restoration of connections to read-only files

3
All of item 2 plus the restoration of connections to all files and any file locks

4
All of item 3 plus the restoration of connections to all files open for write

5
Same as 4

Burst Mode
Burst mode improves network traffic performance by allowing multiple packets to be sent before an acknowledgment is received. If the value is set to off then an acknowledgment will be expected for each packet sent. The setting is available under Windows NT/2000 only. If your network is typically free from errors, it is certainly advantageous to have this set to on.

Cache NetWare Password
The setting can have values of off or on and is available under Windows 95/98 only. If the value is set to on, the username and password pair is stored in memory so that if you wish to access a subsequent network resource, such as another server, you will not have to re-enter your credentials. The password is only cached for the duration of the login session.

Cancel Desktop Login
This setting is valid under Windows 95/98 only, where it ensures that only a successful login through the client will permit access to the workstation.

Checksum
This setting is available under Windows 95/98 and defines a checksum that can be performed on NetWare Core Protocol (NCP) packets. The values can be set as follows:

0
Disabled

1
Enabled but not preferred

2
Enabled and preferred

3
Required

Required
The checksum has an obvious overhead in that it must be calculated and inserted at one end and calculated and checked on the other end. If you have a requirement where the delivery of data needs some level of validation, then you may opt for a value of 2 or 3. If you explicitly disable the option, any packet received by the client that has a checksum will not have the checksum performed. You may wish to use this function if your network is in some way unreliable and there is no check performed on the Data Link or Network Layer protocols.

Close Behind Ticks
This setting is available under Windows 95/98 only and defines the time in ticks for the client to wait before removing a file from the cache by writing it to the disk.

Delay Writes
The Delay Write works along with Close Behind Ticks and declares that a file should remain in the cache for the time defined. The setting is available under Windows 95/98 only and is used when a file is constantly being opened and closed again.

DOS Long Name
When this option is set to on, long filenames from NetWare volumes will be visible to DOS programs. This option obviously expects that the DOS program itself supports long filenames.

DOS Name
This setting is available under Windows NT/2000 and Windows 95/98. It sets the value of the environment variable OS to a value that can be used in the login script. The value can be set to anything; the limit is five characters.

End Of Job
The End Of Job function was used prior to DOS Version 3.0 and is used to release resources when a task is complete. This value should be set to off unless you have some particularly ancient DOS programs to support. The function is available under Windows 95/98 only.

Environment Pad
Under Windows 95/98 the environment for DOS applications can be set with this function. If you have DOS programs that need lots of environment space, then extra space can be granted here. It should be noted that this is a global setting that will allocate this amount of environment for all DOS programs.

File Cache Level
This setting is available under Windows 95 and defines how the data cache works as follows:

0
Disabled

1
Read ahead and write behind

2
Short-lived caching

3
Long-lived caching

File Write Through
This option is available under Windows 95/98 only and sets all caching for file write mode to off. When the setting is set to off, the client waits for an acknowledgment that the file write is committed before continuing.

Force First Network Drive
Under NetWare, a connection must be made to the login directory on the sys volume during the login and logout process. This connection is made to the first network drive, which must also be set and is discussed earlier in the chapter. If this setting is set to on, this drive will be used for the process. This setting is valid for Windows 95/98 only.

Handle Network Errors
In the event that a server does not respond to a request for resource from the client an error is generated. This setting determines whether the client handles the error condition or the application that requested the resource. This setting is available under Windows 95 only and the outcome of this condition will also affect the Net Status Busy Timeout and the Net Status Timeout settings.

Hold Files
This setting is in place for old applications which use FCB_IO. These applications may wish for the files to be left open during the application execution, which is what will happen if Hold Files is set to on. It is probably best to leave this set to off unless you have applications that particularly need the file to be kept open in this way. This setting is valid for Windows 95/98 only.

Large Internet Packet Start Size
This setting is available under Windows 95/98 and Windows NT/2000, where it is designed to go with the Large Internet Packets setting. When the negotiation for the Large Packet begins, it may take several rounds before the negotiation concludes. This setting will define the initial starting point for the process to reduce the negotiation time.

Large Internet Packets
The default packet size is usually set to 576 bytes, but can be increased for performance if the network equipment will allow it. The new packet size is negotiated between the client and the server. The setting is available under Windows 95/98 and Windows NT/2000.

Limit SAP Broadcast Queries
A server can be located via a Service Advertising Protocol (SAP) broadcast or via a bindery query. When this setting is on, the server lookup is first performed via bindery lookup and then via SAP if the lookup fails. The setting is only available under Windows NT/2000.

Link Support Layer Max Buffer Size
This setting is available under Windows 95/98 and Windows NT/2000 and is primarily for use with Token Ring Networks. It can range from 638 to 24,682 bytes. The default value for this setting is 4,736 bytes and should be left at this value unless you are quite sure that you know the value can be safely increased.

Lock Delay
When a shared file needs to be accessed on the server and a lock needs to be placed on the file for some reason, the client may have to wait if the file is already locked by another client. The value specifies the time that the client will wait before giving up the lock establishment. The value is in ticks and can range from 1 to 65,535. If you receive errors from the workstation software or from SHARE then increase this value. The setting is only available under Windows 95/98.

Lock Retries
This setting is similar to the Lock Delay setting above, except that it defines the number of times the file access attempt is made. It is available under Windows 95/98 only.

Log File and Log File Size
If you wish the client diagnostics enabled, you will need to enter a value of NWEnable Logging=True in System.ini. This setting determines where the log file is to be located. The Log File Size defines the maximum size of the file. When the file becomes full the older information is flushed. The settings are available under Window 95/98 only.

Long Machine Type
This setting is available under Windows NT/2000 and Windows 95/98 and sets the MACHINE environment variable. This variable is useful for setting a particular machine type that may need a slightly different executable program. In this case the variable can be used in the path to the executable. The variable was originally provided for backward compatibility of DOS programs so that different versions of DOS could be provided for different machines.

Max Cache Size
This setting is available under Windows 95/98 only and relates to the other cache settings such as File Cache Level and File Write Though. The setting defines the actual maximum size of the cache used by CLIENT32.NLM. This is usually automatically set by the client as 25% of the free memory available during the client program load. This setting is achieved by setting the value to zero. The cache can be set to a different level if desired, but the value should not exceed 75% of total free memory.

Max Cur Dir Length
Some very old DOS programs will not allow filenames with directory paths greater than 64 bytes. Applications that require a short path will be prevented from having problems in this regard if the path is deliberately disallowed from exceeding this maximum length. The setting is available under Windows 95/98 only.

Max Read and Write Burst Size
These two settings define the maximum size for the Read or Write Window Size for a Packet Burst. They are normally set dynamically by the client according to how busy the network is. Don't change them unless you are sure of what you are doing. The setting is available under Windows NT/2000 only, but is functionally the same as Packet Burst Read and Write Window Size under Window 95/98.

Message Timeout
This setting is available under Windows 95/98 only and defines how long to wait before a broadcast message is cleared from the screen. The unit in this case is ticks and the value can range from 1 to 10,000 with 18 ticks per second. A value of 2,160 (2 minutes) seems reasonable for most users.

Minimum Time to Net
When using very slow WAN lines, a connection to a server may fail. This setting increases the wait time for a successful connection. The setting is available under Windows NT/2000 and Windows 95.

Name Cache Level
The cache in this case refers to the cache of server names held by the client. There is an overhead to holding names in cache but as always there is a trade off as performance will be degraded if the client has to constantly wait for name lookups to occur. The setting is available under Windows 95/98 only.

Name Resolution Timeout
Servers and their corresponding addresses are held by a name space provider. This setting allows you to increase or decrease the time that the client will wait for a name to address resolution from the name space provider. The setting is available under Windows NT/2000 only.

NCP Max Timeout
This setting is available under Windows 95/98 only and defines the maximum retry time for retrying a network service before sending an error message. The default setting for this is 30 seconds.

Net Status Busy Timeout
This setting is available under Windows 95/98 only and is relevant only when the Handle Net Errors setting above is set to off. This setting defines how long the client waits for a server response before putting up an error message.

Net Status Timeout
This setting is very similar to the Net Status Busy Timeout setting except that it waits for a network timeout rather than a server timeout. The timeout value is given in seconds, but the value must be set to at least four times the round trip time to the network. If the network roundtrip to the server is 5 seconds, the value will be at least 20 seconds, but will be higher if you have it set to a higher value. The default value for this setting is 30 seconds but can be set to a value up to 600 seconds. If your network or server is very slow and you need to force the client to wait for a response, then this value can be increased. The setting is available under Windows 95/98 only.

NetWare Protocol
When the NetWare client first connects to a server, it will use this order of protocols to initially establish the connection for NDS or Bindery (BIND). The default order is NDS BIND, BIND NDS, NDS, and BIND. This configuration setting is only available under Windows 95/98.

Network Printers
This setting simply sets the number of LPT printer ports available for redirection on the workstation to a maximum of nine and is only available under Windows 95/98. There is a small memory overhead to setting this value high so it may be beneficial if it is set as low as possible. Each printer port will use 103 bytes of memory, from the formula:

Memory = Num_of_Ports × (size_of_header + size_of_tail + 23 bytes)

The default value for the header is 64 bytes and for the tail 16 bytes, as discussed later in this chapter. By increasing those values, the total memory usage on the workstation per port will need to be multiplied by the number of LPT ports defined here.

NWLanguage
Set this value to your language (English if you speak English). The setting is only available under Window 95/98.

Opportunistic Locking
This setting is available under Windows NT/2000 and Windows 95/98 and when set to on will exclusively cache a file to improve performance when the opportunity arises.

Packet Burst
This setting is used by Windows 95/98 to increase network performance by reducing the number of packets sent. This is accomplished by allowing a packet Acknowledgement (ACK) to be sent only after several packets are received. If the value is set to off, an ACK will be required for each packet. The advantage to Packet Burst is clearly network throughput, but it should only be used on a reliable network such as a LAN. You may find that your WAN is very reliable as far as errors are concerned so Packet Burst may realistically be introduced in that case.

Packet Burst Read and Write Window Size
These two settings are available under Windows 95/98 and define the maximum size for the Read or Write Window. They are normally set automatically by the client according to how busy the network is. Don't change them unless you are sure of what you are doing. The settings are functionally the same as Max Read and Write Burst Size under Window NT/2000.

Polled Broadcast Message Buffers
This setting is only available under Windows 95/98 and sets the number of messages to be retained by the broadcast messenger. This setting should only be set if you have a client that needs to keep a certain number of old messages for some reason. The default value for this setting is zero.

Print Header and Tail
These settings are available under Windows 95/98 only and define the size of the head and tail of a print job that is spooled from the client. The default values to be used here are 64 bytes for the header and 16 bytes for the tail. If you wish to increase these values for some reason, such as using the printer for a particular form that is not supported in the driver, then increase the size here, but remember that it will affect the value of the network printers' total memory in use for each port.

Read-Only Compatibility
This function is present to allow a read-only file to be opened with a read/write without giving an error. The function will only allow the lock to be placed and any attempt to write to the file will produce an error. This setting is supplied for programs that insist on opening a file read/write but never need to write to it. The client will respond to the file open read/write request with a success message even though the file is actually only open for read. The function is only present under Windows 95/98.

Receive Broadcast Messages
Broadcast messages are used by the system administrator and the server to send informational or urgent messages to the workstation users and, when enabled on the client, messages can be sent from a workstation to other users on the network. This setting allows you to define which messages will be received by the workstation. The following list describes the possible values.

All
To receive messages from servers and clients

Server
To receive messages from the server only

None
To receive no broadcast messages at all

The setting is available under Windows NT/2000 only.

Remove Drive From Environment
Under NetWare, a drive can be mapped as a search drive. Search drives are used by NetWare to allow programs to be executed when not in the current directory and not in the path. The drive is connected to a NetWare volume and optionally to a directory within that volume. When the drive is connected it can be viewed with its entire path or root connected to another drive. When the drive mapping is deleted, the search mapping is usually removed also. If this setting is set to off, then the search drive will remain in the path.

Resolve Name Using Primary Connection
When this setting is on, only the Primary IP connection will be used for TCP/IP name resolution. If it is set to off all TCP/IP connections will be used for name resolution. This setting is available under Windows 95/98 only.

Search Dirs First
When you issue a DIR command, what appears first, files or directories? If this feature is set to on you will see the directories listed first. The setting is only available under Windows 95/98.

Search Mode
This setting is designed to assist with the location of executable files (.exe or .com) when they are not in the path. Search mode is only available in Windows 95 and can be one of the following:

Mode1
Search for the image in the search drive if there is no complete path in the application execution and the file is not in the current directory

Mode 2
Don't look in any search drives

Mode 3
Just as Mode 1 but find read-only files

Mode 5
Search on all paths

Mode 7
As Mode 5, but search for read-only files

The setting invites the possibility for users to either run programs that they shouldn't be running or programs that they didn't intend to run. This setting should be disabled (Mode 2) but the default value is Mode 1.

Send Message
As well as receiving messages on the workstation, this setting provides the user the option to send messages. This setting is available under Windows NT/2000 and Windows 95/98 and can be set to on or off.

Set Station Time
Under Windows NT/2000 and Windows 95/98 this setting will synchronize the workstation time with the NetWare server.

Short Machine Type
This is a backward compatible function that is available under Windows NT/2000 and Windows 95/98, and is used for setting the SMACHINE environment variable for DOS overlay files. The value is limited to four characters.

Show Edit Login Script Item
As well as a global login script, a user is able to have his own login script which is stored in the user object. The setting is available under Windows NT/2000 and Windows 95/98 and when set to on will show the Edit Login Script item through the Novell menu in the system tray.

Show Novell System Tray, Scheduler Icons, and Administration Menu
There are several features available from the system tray that users may wish to take advantage of. These include functions, such as drive and printer mappings. Administrative settings such as allowing the user to edit his personal login script are also included here. If you do not wish the user to have access to these items, they can be disabled here. These settings are available under Windows NT/2000 and Windows 95/98.

Shrink Path To Dot
This setting is applicable to search drives only where the value of off will permit the full path of the search drive in the path, or on when the search drive root will only be permitted.

Signature Level
This setting is available under Windows 95/98 and Windows NT/2000 and sets the security level for packet signatures by signing the first 64 bytes of the packet. The values can be:

0
Disabled

1
Enabled but not preferred

2
Preferred but will not enforce if the server does not allow it

3
Required

The server(s) should also have the appropriate level set by issuing the command: SET NCP PACKET SIGNATURE OPTION = value.

This setting is quite useful for protecting data on your network. If you set the value to 3, you will need to make sure that all your servers have the value 3 set also. A safe value is 2 and the default value is 1. The client's network performance will be slightly degraded as the value increases.

True Commit
This setting is available under Window 95/98 only and may be worth consideration if the client workstation handles critical data. The data will not be cached on the workstation or server, but will be written to disk immediately. There is an obvious performance overhead to having this setting on, but if data integrity is an important issue, you may consider the trade-off worthwhile.

Use Extended File Handles
This setting is available under Windows 95/98 and allows the number of file handles to be increased from the default of 170 to whatever the maximum Locks Per Connection value is set to on the server.

Use Video BIOS
This setting is valid under Windows 95/98 and relates to the speed of video for message pop-up boxes when running in DOS mode. In general, the video through BIOS is slower for graphics and faster for character-based DOS windows. The default value for this setting is off and should be left at that setting unless you are experiencing very slow or non-functioning message boxes.

There are other pages in the Client Configuration pages that really speak for themselves, such as Default Capture, which allow you to define settings for networked printers, as shown in Figure 3-3. These other settings are just as important as those complicated advanced settings; appearance and completeness are always desirable in any service delivery.

Figure 3-3. Default Capture

 

Protocol Preferences

The Windows NT/2000 and Windows 95/98 client can use the IPX transport protocol to communicate with NetWare servers. If you are using NetWare 4 or 5, you can also use TCP/IP as a transport protocol. The NetWare client for Windows NT/2000 and Windows 95/98 does not install any base transport protocols, because these protocols are supplied as part of the protocol suite within the operating system. However, they must be installed on the workstation prior to the client installation.

For many years, Novell used IPX as their mainstay network transport protocol and for this reason there are a great many IPX transport-dependant applications, both for client and for server, that required some kind of IPX transport. Novell recently committed themselves to using TCP/IP as their main transport in two products called NetWare IP and Pure IP. These two products are confusing because they appear to be the same, but hardly are. NetWare IP does not transmit TCP/IP on the wire, but actually encapsulates TCP/IP in IPX packets and unpacks them on the server. This is not a true IP transport and is generally recognized as such. The Pure IP product is actually a true TCP/IP transport, but is only available under NetWare 5. Many IPX-dependant applications are now IP-aware to the extent that the IPX transport is no longer required in some organizations.

In general, it is possible to use one or all of these two protocols between the workstation and the server in the following combinations:

IPX only
This configuration will work only when IPX is installed and running on the server and IPX/SPX is installed and running on the workstation. IPX is the main protocol used by NetWare 3.x and 4.x servers and is available in NetWare 5.

IP only
Similar to IPX only, but the workstation will not be able to talk to IPX-only servers. The Pure IP product is only available as a transport from NetWare 5 servers. Although IPX is still available if you have only NetWare 5 servers, you may want to consider TCP/IP as your only transport protocol.

IP and IPX
This will allow the client to participate in networks with servers running both protocols. This may be the desired setup for a NetWare 5 and NetWare 3 or 4 environment.

IP with IPX compatibility
This will use IP for its main transport protocol, but will communicate with servers running NetWare 5 with the migration agent installed to support IPX. This configuration is best if you wish to use Pure IP only, but have some IPX-aware applications still in use.

The use of IP on a NetWare network will probably require the use of the Service Location Protocol (SLP) as a mechanism to discover servers and other network services. The SLP does not need to be specifically routed as it uses the User Datagram Protocol (UDP) and the TCP protocol to perform discovery.

TIP:  

If you wish to use TCP/IP as a transport and do not want IPX, then this is the direction Novell would probably want you to go in. For those IPX-aware applications still in use with no immediate upgrade path, use IPX compatibility mode to provide the functionality without installing the IPX transport.

Layered on top of these transport protocols are transport interfaces such as NetBIOS and Windows Sockets. The interfaces allow Server Message Block (SMB) data through the NetBIOS interface and datagram services via the socket interface, as shown in Figure 3-4.

Figure 3-4. Supported protocols

 

The Windows NT/2000 Client

The NetWare Client for Windows NT/2000 supports authentication to NetWare servers that use NDS and Bindery. Unlike Windows 95/98, Windows NT/2000 is a secure operating system where processes running in user mode, which is where the user's application runs, are secured from unsupported access to processes running in kernel mode, which is where the operating system and its components run. The NetWare client provides 16- and 32-bit libraries and interfaces that run in user mode. These libraries pass compliant information to the Windows NT Executive services running in kernel mode.

Windows NT/2000 Client Architecture

The Windows NT/2000 system architecture is shown in Figure 3-5. Unlike DOS and Windows 3.x, Windows NT/2000 was designed from the ground up with network services fully built into its architecture. The NetWare client has to interface with the complex executive services layers running in kernel mode. To achieve full integration with the Windows NT/2000 operating system, the Client software meshes into the system architecture to provide full, integrated NetWare services to the workstation. These services provide support for the following areas:

The Windows NT I/O Manager is part of the executive services and dictates how all the input and output in the operating system is managed. This includes requests from the user in user mode for resources and applications in user mode requiring resources. The I/O Manager performs several functions, and the following are relevant to the discussion:

Filesystem drivers and redirectors
There is accommodation for more than one filesystem driver in the operating system and, in general, most workstations will have a NTFS filesystem driver (NTFS.SYS) and a CD-ROM driver (CDFS.SYS) in use. These drivers also provide a redirector as part of the device driver architecture. The redirector takes the request for data from the mapped network drive and converts it to a format that can be accepted by the I/O manager. The NetWare Client provides support for a new filesystem driver called the NetWare File System driver (NWFS.SYS) also with a built-in redirector.

Multiple Universal Naming Convention Provider (MUP)
The MUP resolves Universal Naming Convention (UNC) paths and determines which redirector should be used to provide the service.

Transport Driver Interface (TDI)
This is an interface provided for filesystem drivers to communicate with available transport protocols to provide the service.

NetWare Filesystem Integration

The NetWare filesystem (NWFS) and redirector interface directly with the I/O Manager, which is part of the Executive Services running in kernel mode. There is also built-in support for applications running in user mode with modules running to cater to 16- and 32-bit programs requiring appropriate access to the NetWare filesystem. The NWFS communicates with the MUP and the TDI, as shown in Figure 3-6, to provide a fully integrated filesystem component.

Figure 3-6. The I/O Manager

 

The client installation contains no new transport protocols, but uses the Windows NT IPX/SPX and TCP/IP built-in protocols.

Windows NT/2000 Support for Open Datalink Interface

The Windows NT/2000 transport protocols use NDIS as the interface to network hardware. This interface provides a standard through which all network communication can occur, providing reliable support to the I/O Manager and other services.

The Windows NT/2000 client gives provision for Open Datalink Interface (ODI) via the NDIS network layer, by providing the ODI support layer below it, as shown in Figure 3-7. The ODI functionality should only be used if you require backward compatibility for ODI-aware applications. There are very few ODI drivers available for Windows NT/2000 and you should certainly consider using the NDIS layer exclusively unless you have a very specific case requiring ODI functionality.

Figure 3-7. ODI support layer

 

NetWare Aware Application Support

The Windows NT/2000 virtual DOS machine can provide backwards compatible support for API calls to Virtual Load Modules (VLM) and IPX from DOS programs, through a Terminate and Stay Resident (TSR) program that is loaded from AUTOEXEC.NT. These TSRs intercept the API calls and route them through the 32-bit client libraries running in user mode and pass them to the I/O Manager. These VLM and IPX support modules are also used to support backward compatibility in 16-bit Windows programs.

Windows 32-bit applications requiring NetWare API calls are passed directly to the Novell 32-bit client libraries running in user mode, as shown in Figure 3-8.

Figure 3-8. Windows NT application support

 

The Login Process

The normal login process under Windows NT/2000 uses a Graphical Identification and Authentication (GINA) component called MSGINA.DLL. This provides the user with a mechanism to enter the login details to authenticate to a Microsoft network. The NetWare client installs a new GINA called NWGINA.DLL, which replaces the Microsoft GINA as the Login Dialog Box greeting the user when he first logs in. The authentication GINA used for this purpose is stored in the registry location shown in Table 3-2.

Affected keys
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon

Table 3-2: The Login GINA

GINA

Value Name

Data Type

Value

Microsoft

GinaDLL

REG_SZ

MSGINA.DLL

NetWare

GinaDLL

REG_SZ

NWGINA.DLL

During the machine boot process, the Winlogon process reads this registry key and launches the GINA. The GINA requests the user to enter the login username and password pair that is passed to the NDS for authentication. After this authentication has occurred to the NDS, a subsequent authentication must be made to Windows NT. At this stage, the username and password pair are compared in the local machine and, if matched, allow the user into the workstation. The process of local authentication is carried out by Winlogon, which opens the workstation's SAM database with the username and password pair used for NetWare authentication. If the username and password pair do not match, the user is asked for a valid pair for the workstation. Access to the workstation will not be granted unless a valid pair is established.

If the Workstation Manager is running on the workstation and a Dynamic Local User policy is enabled in the NDS and associated with the user, a username and password will be created on the workstation. This allows the user to gain access to the workstation without a local user ID and password. The operation of the Workstation Manager is discussed later in this chapter and the Dynamic Local User Policy is discussed in Chapter 4.

The Network Provider

Windows NT/2000 permits a number of network service providers to exist within the network architecture. To accomplish this, each service provider must have its own network provider. The Microsoft provider is called NTLM, which services requests for LAN Manager functionality. This provider handles requests for Server Message Block (SMB) to LAN Manager-compliant servers, which underpins higher level services such as file and printer sharing. The Novell Network Provider for NT (NOVNPNT ) sits alongside the NTLM, providing services to NetWare servers, which fully integrates into the Windows NT/2000 desktop environment.

Network-aware applications can use several mechanisms to establish a route to a resource, such as server or printer information. One such mechanism is a UNC connection, which routes through the MUP. The other is the Windows Networking API (WNet), which routes through the Multiple Provider Router (MPR). The MPR routes specific requests for Microsoft services through the NTLM provider (NTLM.DLL) and NetWare services through NetWare Provider (NOVNPNT.DLL). These service requests pass either through the Workstation Service or the Novell 32-bit client libraries, both running in user mode. The request is then passed directly to the appropriate filesystem redirector, as shown in Figure 3-9.

Figure 3-9. WNet application handling

 

The WNet integration allows applications such as Network Neighborhood and My Computer to handle NetWare service requests such as authentication, browsing, and drive mapping. It is also a very useful tool for getting NetWare volume information by right-clicking a volume icon and selecting Properties, as shown in Figure 3-10.

Figure 3-10. NetWare volume properties

 

Managing NetWare filesystem trustee rights and attributes is much easier through the GUI than having to use the RIGHTS, GRANT, and REVOKE commands from the Windows NT DOS command line. The attribute of a file can be viewed or modified through checkboxes when the File tab is visible. The rights function is more complicated, but you are essentially able to set effective rights to files or directories. This is accomplished through the rights page shown in Figure 3-11, by adding, modifying, or removing multiple trustees to the file and by assigning rights to the trustee. It is not possible (for security reasons) to modify Supervisor rights, although they are viewable in the page shown in Figure 3-12. Supervisor rights must be set through the NWADMIN program.

Figure 3-11. NetWare rights

 

Figure 3-12. Trustee rights

 

The Print Provider

The functionality for print services is similar to the Network Provider discussed earlier in that it also uses the WNet API. The print job is passed through the Windows NT/2000 printer interface and then on to the Print Provider Router. The job is handed to the NetWare Spooler (NWSPOOL.DLL) and subsequently down through the network stack, as shown in Figure 3-13.

Figure 3-13. The Windows NT Print Provider

 

The Windows 95/98 Client

The Windows 95/98 client provides similar NetWare integrated functionality to that provided under Windows NT/2000 described earlier. However, the Windows 95/98 system architecture is quite different from Windows NT/2000 and, as a result, the integration is accomplished in a different way. The client is fully able to communicate with NetWare NDS and bindery-based servers and does so in a similar way to Windows 3.x; indeed, the code is based on the Windows 3.x 32-bit client.

Windows 95/98 Client Architecture

Windows 95/98 is a 32-bit operating system, which, unlike Window 3.1 and DOS, has networking built into the system architecture. The NetWare client for Windows 95/98 will not install any transport level network drivers and can use either NDIS or ODI LAN drivers for communication to the network hardware.

Figure 3-14. Window 95/98 architecture

 

The client architecture of Windows 95/98 is shown in Figure 3-14 and is different from the Windows NT/2000 architecture. NT uses a redirector and filesystem driver whereas the Windows 95/98 client is more similar to the Windows 3.1 client, which also uses the NetWare I/O Subsystem (NIOS). This subsystem uses WNet APIs to handle its networking requirements. The Windows 95/98 operating system has full support for 16-bit applications by providing a 16-bit API to WNet, which is passed to the 16-bit user interface, user.exe. It is then handed on to the Multiple Provider Router (MPR). The application API functionality is discussed in the section "The Login Process."

The NetWare client is implemented as an interrupt 21 shell. Because there is no workable API operating above the IFS manager, the NetWare client intercepts interrupt 21 and processes the information to ensure that any NetWare resource requests are routed through NetWare Client NIOS and any Microsoft requests through the IFS manager. The NetWare client provides the following functions:

NetWare Filesystem Integration

Microsoft uses filesystem drivers to provide filesystem redirection. These drivers are implemented as virtual (VXD) device drivers which are written in assembler and execute at ring zero. This is the mechanism used by Intel to gain access to resources in protected mode.

Figure 3-15. Microsoft and NetWare filesystem drivers

 

The Microsoft 32-bit redirectors use a Virtual Memory cache, implemented as a device driver that therefore runs in protected mode. This driver (VCACHE.VXD) is a wider ranging and smarter version of the Windows 3.x SMARTDRV.SYS, providing a dynamic memory pool and support for CDFS filesystems previously managed by MSCDEX.EXE, as shown in Figure 3-15.

The client for Windows 95/98 Network provider does not use the VCACHE.VXD for its memory management. It instead uses a separate cache provided by the NIOS interface. The NIOS is loaded through a Virtual Device Driver (LOADER.VXD), giving all the NLMs in the client kit access to extended memory. This includes the NIOS.NLM I/O Manager and the CLIENT32.NLM client requester that is responsible for all filesystem functionality and service tracking.

The Microsoft networking functionality is provided by a protocol called Server Message Block (SMB). This protocol allows services to be provided from Microsoft Servers and is also used for peer-to-peer communications. The NetWare equivalent of this is the NetWare Core Protocol (NCP). It is installed as part of the 32-bit Windows 95/98 client and works through the session multiplexor for the provision of NetWare file services.

Windows 95/98 Support for Open Data Interface

Under Windows 95/98, the Microsoft-provided ODI support module exists as a shim below the NDIS layer between it and the network hardware. After the Client 32 Software has been installed, the support for ODI is provided by placing an ODI driver beside the NDIS layer. This driver shim communicates between the Link Support Layer (LSL) and the network hardware, as shown in Figure 3-16. There is also provision in this model for NDIS support with the provision of a shim above the NDIS layer to provide LSL to NDIS translation.

Figure 3-16. ODI support in Windows 95/98

 

Support for 16-bit ODI drivers is provided for with the provision of a layer between the LSL and the 16-bit real-mode driver. This is provided via a 32- to 16-bit translation NLM, which is an ODI driver as far as LSL is concerned, but actually provides an interface between the two layers.

Application Support

Windows 95/98 is Microsoft's direct replacement for DOS and Windows 3.x and, because of this, it not only has to be able to handle 32-bit applications, but 16-bit applications, even catering to DOS real-mode demands as well. This places challenges not only on the operating system, but also on the NetWare client's backward compatible support provision.

Figure 3-17. Windows 95/98 application handling

 

The Login Process

The login process under Windows 95/98 is not strictly necessary, but if the Microsoft client is installed in the network stack, then it will be presented to the user during the boot process. This client provides the user with a mechanism to enter the login details to authenticate to a Microsoft network.

After the NetWare Client has been installed, a new GUI login utility (LOGINW95.EXE) is presented to the user allowing authentication to a bindery or NDS NetWare network. There is provision for login script execution and support for Workstation Manager desktop management. The NetWare GUI login utility is similar to the Microsoft client in which you can simply cancel the login and gain access to the local system. This feature can be disabled through the use of a policy that can be forced on the user provided the policy is enabled as described in Chapter 4, and provided the Workstation Manager is running on the workstation as described in "The Workstation Manager," later in this chapter.

During the Windows 95 boot process, the NetWare login program automatically starts asking the user for login credentials. The user enters his username and password, which is then passed to the network provider for authentication. Upon successful login to NetWare, the username and password pair is cached and subsequently used for access to the Windows 95 workstation. Access to the Windows 95/98 operating system can be made a great deal more secure by using a policy to force authentication before access is granted. These policies are discussed in detail in Chapter 4. The program will then start to search the tree for a policy associated with the user and, when it is found, allows the Workstation Manager to execute it.

The Network Provider

The Windows 95 networking architecture allows for more than one provider of network services. In order for NetWare services to be fully accessible, the client installation installs provider software allowing NetWare services to be fully integrated into the desktop environment. Under Windows NT/2000, the provider specifically requires WNet functionality to support the provision of desktop integration. In the case of Windows 95/98, this is supported because most services under Windows 95/98 are supplied via WNet anyway.

The Windows 95/98 provider allows utilities such as My Computer, Network Neighborhood, and the Windows Explorer to be fully functional with NetWare services including:

The connection and execution of services via standard UNC pathnames is also supported via applications and shortcuts. The NetWare volume information is also available by right clicking a volume icon and selecting Properties. This is very similar to the tool available under Windows NT/2000, shown earlier in Figure 3-10.

The DOS utilities for managing NetWare filesystem trustee rights and attributes is provided for via a GUI. This is also made visible by right clicking a volume, folder, or file in the browser window. The attribute of a file can be viewed or modified by selecting the File tab. The GUI rights function is available and, as with Windows NT/2000, allows you to set effective rights to files or directories by selecting the Rights tab, which is similar to that shown earlier in Figure 3-11. Trustee rights can also be assigned through the GUI by adding, modifying, or removing multiple trustees to the file, similar to that shown in Figure 3-12. As with Windows NT/2000, it is not possible to modify Supervisor rights, although they can be seen within the page. Supervisor rights must be set through the NWADMIN program.

The Print Provider

Windows 95/98 does not require a physical device port such as LPT1 to be redirected for printing to occur via a network print queue. The printer can be added in the standard way via the Add Printer function, allowing you to browse the NDS and select an already installed print queue. Select a print driver in the usual way and the printer will be set up.

The Windows 3.x Client

Windows 3.x is an addition to DOS that allows GUI programs to be run in extended memory. The architecture of Windows 3.x had no allowance for networking until Windows 3.11 for Workgroups arrived, and then networking was really only an add-on for Microsoft networking.

The NetWare Windows 3.x client is a 32-bit protected-mode interface that adds networking functionality without using real memory. The client does not require a DOS network layer, but provides a protected environment similar to the NetWare server architecture. There is provision for NetWare Loadable Modules (NLMs) that are loaded into extended memory.

Windows 3.x Client Architecture

The Windows 32-bit client is built around the NetWare I/O Subsystem (NIOS), and provides an interface between the client 32-bit protected-mode environment and the operating system. This component (NIOS.EXE) is loaded to provide the flatmemory environment for the NLM launcher. The NIOS subsystem requires a memory manager (HIMEM.SYS) to be present on the workstation as it does not have its own memory manager.

There are clear advantages to using the 32-bit Client because of the way it uses extended memory rather that the DOS components in real memory. This is particularly the case where the workstation has devices requiring device drivers loaded into real memory such as CD-ROM and multimedia devices. The addition of these devices, together with the standard DOS network stack, place exceptional requirements on the memory below 1 MB. The result of an overloaded real memory is that you may be able to load Windows, but can run very few programs.

Because the NIOS system loads the network stack into extended memory, you will need to ensure that the machine has sufficient memory to allow for this and any Windows requirements.

The Windows 3.x Client 32 communicates to network services using the ODI. The network components are loaded into extended memory and include a Link Support Layer, an IPX protocol support module, Virtual Load Module along with TCP/IP, and several others that you may optionally load to support configuration (see Figure 3-18).

Figure 3-18. NIOS architecture

 

The Client 32 Requester is a major component which supports a host of functions, all of which are contained in CLIENT32.NLM. This mode provides support for file redirection, print services, NDS and bindery support, along with NETX and VLM-aware DOS application support.

The Workstation Manager

During the client installation, discussed in Chapter 2, The ZENworks Installation, one of the installation options is a component called the Workstation Manager which runs on the client. This component faithfully carries out your work. The tasks performed by the Workstation Manager vary from creating and deleting accounts on the local NT Workstation, making changes to the registry, and running inventories to collect hardware or software information.

The work carried out by the Workstation Manager is centrally configured in the NDS policy objects associated with the operating system platform. These policy objects target either users or workstations according to the type of work being done. All work done by the Workstation Manager under Windows NT/2000 is run with System privileges so that the user has no need for any extra workstation rights. The policy objects are covered in detail in Chapter 4.

The Login Process

During the user login process, the NWGINA will check the user object for a policy associated with it. If the policy is present, it will be opened and any work to be performed will be inserted into the schedule to be executed at the appropriate time. If a policy is not found for the individual user object, then any group objects associated with the user will be checked for associated policies. If the user is a member of more that one group, the first group to have a policy will have the policy obeyed and all other groups with associated policies will be ignored. If no groups are found with associated policies, the user's parent container will be checked and then the parent above that and so on until the search reaches the root of the tree.

The Workstation Manager has a few configuration details, as shown in Figure 3-19. These details allow you to enable the Workstation Manager and to enter the trusted tree. The Workstation Manager is enabled when you install it. If for any reason you wish to disable it, say, for some test purpose, you may do so here rather than uninstalling the component.

Figure 3-19. The Workstation Manager configuration page

 

The trusted tree is a very important concept. You must indicate which trust is granted to which tree. The work carried out by the Workstation Manager is run with system privileges and only the work defined by you should be allowed to be carried out. A good example of this is account creation under Windows NT/2000 via Dynamic Local User. When this policy is enabled in the Windows NT/2000 User Policy, the Workstation Manager will create the account on the workstation, allowing you to log in.

While this is an essential part of the Windows NT/2000 workstation authentication process, it can be seen as a potential security loophole for Windows NT/2000 workstations, if the trusted tree setting is allowed to be modified by users. The security of the system can be compromised if another NetWare tree was installed by a user within your organization. If the user is able to modify the trusted tree setting, then he may be able to gain privileged access to the workstation. The user would only have to enter his tree from the NetWare Login Dialog Box and have a policy obeyed that grants access with Administrator privileges. The best way of avoiding this problem is to define a trusted tree in the Workstation Manager dialog box and protect it from the users. In addition, it is beneficial to disallow the users from seeing the Advanced button in the Login Dialog Box.

WARNING:  

The trusted tree is important for Windows NT/2000 users. It must be protected against users who may modify the tree name to attempt to gain privileged access to the NT Workstation. In general Windows NT users are given user access to the workstation. Any attempt to assign greater rights to the user could breach the security of your NT workstations.

The login process begins with the operating system, the NetWare client, and then the Workstation Manager. We shall examine the whole process for Windows NT/2000, Windows 95/98, and Windows 3.x to help understand how it works.

Operating system boot
The three operating systems in question boot in different ways, but during that process the client GUI login screen is called to accept the username and password pair.

Authentication
The username and password pair are sent to the NDS and the user object is opened to check if the password is correct. If it is correct, a success message is sent to the client. If not, an error is returned and displayed to the user. The error message will depend upon whether the password was wrong or the user ID does not exist.

Policy check
The NetWare client will check to see if there is a policy package associated with the user and the workstation. If a policy package is found, it will be opened and the contents executed by the Workstation Manager, including creating a local NT account for the user if Dynamic Local User is set in the policy package (see Chapter 4 for more details about Dynamic Local User). In some cases, the work to be performed on the client is not scheduled to run during login, but at another scheduled time or event. In this case the task is stored in the scheduler to be performed by the workstation later. If the Workstation Manager is not installed or is not running, then the policy contents will be ignored. In the case of Windows NT/2000, if the user ID and password matches a local credential set, the user will be logged in. If the credential set is not valid on the workstation, the user will have to enter a valid user ID and password for the workstation before he is allowed to continue the login process.

Continue boot
After the Workstation Manager has finished, the boot process continues and any registry modification made by the Workstation Manager through policies in the policy packages will be valid and enforced when the user shell is executed.

Complete login
The login script is executed and, if the script is executed synchronously, this will have to complete before the user shell is executed and the workstation desktop is built.

TIP:  

If you wish to use policies in the policy packages to force the workstation desktop into a presentable state or to permit authenticated login to Windows NT/2000, you must install and enable the Workstation Manager.

The Help Requester

The Help Requester is basically a tool to enable the user to contact or send problems to the Helpdesk. There are 16-bit and 32-bit versions of the program, allowing it to be used on all supported platforms. The program is opened when the user executes the program, which should be placed in a useful location such as the desktop. The user is presented with a window similar to that in Figure 3-20. This window presents details about who to contact on the Helpdesk and the contact details. There is also a mechanism to allow the user to send a message or query via email.
Figure 3-20. The Help Requester

The configuration details for the Helpdesk are stored in the NDS through a policy package. The policy governing the use of the Help Requester can be configured differently by associating a different policy package for each group of users. More details about how to configure the Help Requester can be found in Chapter 4.

Users frequently have trouble finding out who to contact about a problem, and when they do contact the Helpdesk, they are unable to tell the Helpdesk operator who they are (in NDS terms). This information is available to the user through the Info button. The contact details are displayed, as configured in the policy package, along with the user's login details.

If the user (or you) decides that the best way to get appropriate help is by raising a trouble ticket via an email, then a message can be prepared and sent to a pre-configured email address. The user is able to select a subject line to summarize the problem, which is also preconfigured in the policy package. This will allow the trouble ticket to flow through the Helpdesk email processor (if the function is supported by your Helpdesk software) to the correct software support person. To make use of the email functionality, you will either have to be using Groupwise email or have a MAPI configured agent installed to forward the message.

A Final Word

The ZENworks client is an important and complex part of the product which should give very little trouble. If you do have problems with the client, understanding how it works is really the only way of troubleshooting and fixing the problem. When something goes wrong it is usually for a logical reason. Try to analyze what is actually going on, and you will usually find that the problem is quite straightforward.

Back to: Desktop Management with Novell ZENworks

O'Reilly Home | O'Reilly Bookstores | How to Order | O'Reilly Contacts
 International | About O'Reilly | Affiliated Companies

© 2001, O'Reilly & Associates, Inc.
webmaster@oreilly.com