Novell is now a part of Micro Focus

Printing in NetWare 5 with NDPS 2.0

Articles and Tips: article

Editorial Intern
Novell Developer Information

01 Sep 1998

Find out what the advantages are to using Novell Distributed Print Services (NDPS), the default print services for NetWare 5.


The default print system for NetWare 5 is Novell Distributed Print Services (NDPS) version 2.0. In the April 1998 issue of Novell AppNotes we featured an article about the first release of NDPS (version 1.0) and provided an introduction to its features. As NDPS 2.0 is very similar architecturally to version 1.0, refer to April's AppNote "An Introduction to Novell Distributed Print Services (NDPS)" for basic introductory information about Novell's new print service. This AppNote is also available on the web at

In this AppNote we explain the advantages to using NDPS as the default print service of NetWare 5, look at the improvements made to NDPS 1.0 in version 2.0, and provide some installation planning tips and scenarios.


NDPS was developed to simplify management and reduce the expenses related to maintaining your network's printing system. The functionality of NDPS is possible because of the power of Novell Directory Services (NDS) which allows system administrators to centrally manage the network printing environment from a single NDS object. As NetWare 5's default print service, NDPS offers important improvements in printer configuration and administration over the Novell legacy queue-based print service architecture. NDPS automates and eases most aspects of network-based printing by providing, among others, the following services:

  • Solid integration with NDS

  • Usability in a Pure IP-based or IPX-based environment, or a mixture of both

  • Simplified and centralized administration of all printing resources through NWAdmin

  • Automatic printer driver download and installation

  • Bi-directional feedback and control of printers and print jobs

  • Support for existing printers and printing technologies (full backward compatibility)

  • New printer and job configuration options for specific printers

  • New print job scheduling and notification options (such as scheduling jobs according to time of day or job size)

  • Remote workstation printer management capabilities

These are just a few of the NDPS features that complement the printing experience for adminstrators and users.


NDPS was designed to fully fuction in your current network printing environment and remains compatible with all types of printers, whether or not they have been configured to take advantage of the advanced features that NDPS offers. NDPS can also be configured to work with NPRINTER and queue-based technology in conjunction with NetWare 4.11 and intraNetWare.

The architecture of Novell legacy queue-based print services of the past was based upon the creation and linking of three components: printers, print queues, and print servers. Setting up queue-based printing is still a complex task: in order to print, users first have to capture the printer port. Then the client redirects the data to a file in a print queue, where it was stored while waiting to be sent to a printer by the print server. With NDPS, printer, print queue, and print server functions are combined into a single entity called a Printer Agent. Printer Agents eliminate the need to create print queues and allow users to send print jobs directly to printers.

Even though NDPS does not require queues, your network may continue to include queue-based printers and clients not currently configure to support NDPS. The backward compatibility of NDPS allows you to continue using these queue-based services and resources transparently.

This compatibility allows you to implement NDPS at your own pace, without having to disrupt or modify your current printing configuration. Implementing NDPS is similar to upgrading your old 10-speed bicycle to a 21-speed: you only have to use the extra speeds if you want to improve your functionality. This flexibiliby allows you to change gears at the pace and frequency you are comfortable with, providing a smooth, customizable path to part or full NDPS implementation.

You can print through NDPS to an existing queue, allowing you to access systems that require a queue connection (for example, mainframe systems using NetWare HostPrint and certain proprietary systems).

NDPS can service existing queues, allowing you to use NDPS on the server even though your client platform is not currently running NDPS. This allows you to install and run NDPS while you are changing your client workstations to NDPS.

While providing easier use for users and better management functions for administrators, NDPS also allows you the flexibility to implement the full features and security of NDPS at the pace you want into the unique printing environment of your organization's network.

NDPS 1.0 vs. NDPS 2.0

NDPS 2.0 makes several improvements to the first release of NDPS (version 1.0). Besides the many bug fixes to NDPS 1.0 and native support for IP, NDPS 2.0 also adds the following:

  • Fault tolerance. NDPS 2.0 allows the NDPS Manager to be loaded on other servers. This means that if the NetWare server where the NDPS Manager is running is shutdown or abends, the NDPS Manager will successfully load on to another NetWare server and continue to service printers (except local printers). With NDPS 1.0, the NDPS Manager could not be loaded on to a different server other than the server it was created on.

  • Windows client support. NDPS 2.0 removes the need for Windows NT clients to print to NetWare queues in order to take advantage of NDPS by providing full Windows NT4 support. This means that NDPS printers can be installed on Windows NT desktops to provide all NDPS services to users. NDPS Printers can be installed with the "add printer wizard", through the explorer window, with NWPM.exe, or automatically when the user logs in using NDPS Remote Printer Management.

    NDPS 2.0 also adds support for Windows 98.

  • Remote Printer Management. NDPS 2.0 provides improved Remote Printer Management that is fully integrated with the desktop operating system. NDPS Remote Printer Management can install and uninstall both Controlled Access Printers and Public Access Printers, uses time stamping to determine whether a client requires updating at login time, can install a new driver to an installed printer without removing and reinstalling the printer (local changes to the installed printer are therefore preserved), and is managed through NWAdmin32.exe (printer details, container details, or Tools Menu).

  • LPR/LPD on IP. NDPS 1.0 provided no way to print in IP only environ- ments. NDPS 2.0 provides an NDPS Gateway to support LPR/LPD printing on IP networks.

  • JetDirect on IP. The Hewlett Packard NDPS Gateway that shipped with NDPS 1.0 supported IPX only. The HP Gateway included with NDPS 2.0 can print over both IP and IPX.

  • Xerox Gateway. NDPS 2.0 includes the Xerox NDPS gateway in the box.

  • SMTP notification of printer events. NDPS 2.0 includes a notification method that supports SMTP mail servers. Because most e-mail systems support SMTP, e-mail notification of printer and job events will be available for most MHS systems and GroupWise.

  • Accounting Enabled. NDPS 2.0 includes accounting objects and hooks to support full-featured accounting packages.

  • International Localization. While NDPS 1.0 was localized to Japanese and English only, NDPS 2.0 is fully localized to support Spanish, French, Italian, Japanese, Portugese, German, Traditional Chinese, Simplified Chinese, and Russian languages.

  • Customizable server install. NDPS 2.0 server install can be customized to install only system and public files, allowing you to decide whether or not to install a broker and whether or not to install a resource directory (containing printer drivers and other information). The resource directory may not be needed on every NetWare server (it consumes roughly 80 MB of disk space).

Note: If you have already been using NDPS 1.0 and are migrating your print system to NDPS 2.0, you need to fully deploy the new server and client components to completely replace version 1.0; however, both versions are designed to smoothly function together during the migration transition. Also, NDPS 2.0, when released, will run on your NetWare 4.x servers.

Understanding NDPS Implementation Options and Scenarios

Possible scenarios for printing with NetWare 5 range from maintaining a legacy queue-based system (available only for IPX-based systems), to integrating NDPS into a heterogeneous print system, to implementing NDPS into a Pure IP-based environment. A wide range of heterogeneous configurations exist between all IPX and Pure IP systems, and between all queue-based and all NDPS systems. However, becoming one hundred percent Pure IP and utilizing the most advanced printing features of NetWare 5 implies full deployment of NDPS.

Whether you are migrating to NetWare 5 as an upgrade or installing from scratch, there are several things you need to consider as you implement NDPS based upon your current system configuration, which we discuss below. The NDPS product web site has a helpful white paper (from which much of the following information was borrowed) that might assist you in better planning and preparing for your transition to NDPS. The paper is titled "Planning Your Transition to NDPS" and is located at:

Current Print System

If your current network environment consists of NetWare 3.x or 4.x servers, non-NetWare servers, or a combination of these, the following considerations are listed to help you understand the paths available to you to implement NDPS into your new NetWare 5 networks.

NetWare 3.x Printing System. If you are currently using a NetWare 3.x server bindery and file system and have only a small number of printers, you should consider implementing your NetWare 5 NDPS system from scratch and deleting all of your legacy printing objects. However, if your system is large and you do not want to create your NDPS printing system from scratch, the Novell Upgrade Wizard (which ships with NetWare 5) is a great tool to migrate your NetWare 3.x printing objects across-the-wire to your NDS tree. You can then begin the process of implementing an NDPS printing system on your network as you would in the queue-based printing sytem, as in NetWare 4.x.

NetWare 4.x Legacy (Queue-Based) Printing System. If your current printing system is queue-based, as with NetWare 4.x, you likely have a variety of printer configurations set up on your network: from printers attached to the server or workstations, to printers running through a dedicated print server or through QServer-mode. The easiest course for migrating your printers to NDPS from any of these configurations is by using a third-party gateway.

Note: NetWare 5 ships with the Hewlett Packard and Xerox NDPS gateways. While other third-party gateways are in development, you should contact your printer manufacturer for more information about their availability. If there is not a third-party gateway available for your printer, the Novell NDPS gateway provides a straightforward configuration path to implement NDPS.

NDPS Gateways A gateway is a software bridge which allows NDPS clients to send jobs to printers that are not NDPS-aware and allows NDPS clients to access printers and print systems (UNIX, Macintosh, and so on) that require jobs to be placed in queues. Gateways are configured to identify the specific printer type (make and model) used. This information then allows the gateway to translate NDPS queries or commands to printer-specific language that the physical printer can use.

Non-NetWare System. If you are implementing a new Novell network from scratch, or if you are changing over from a different networking system altogether (such as Windows NT, LAN Manager, 3COM, or others), you should implement NDPS as your initial, primary printing solution. If any of your current printers or print clients still require queues, the backwards compatibility functionality of NDPS allows you to integrate those printers and clients into your system. In all other cases, it is recommended that you use an all-NDPS printing setup.

There are several implementation options available to you and are described in the following sections:

  • Using Legacy Printers and NDPS Gateways

  • Using Printers with Embedded NDPS Technology

  • Maintaining Existing Configurations

Note: As with other printing solutions, in order for users to print, these printers must be installed on the users' workstations. To facilitate management, administrators can remotely install these printers to users' workstations by using NDPS Remote Printer Management.

Option 1: Using Legacy Printers and NDPS Gateways

Currently, the best method available to communicate with a network printer using NDPS is through a third-party gateway designed specifically for that printer or printer family, as shown in Figure 1.

Figure 1: An illustration of how third-party gateways figure into the NDPS architecture.

The scenario in Figure 1 requires two components running on a NetWare server: the NDPS Manager and the third-party gateway. The NDPS Manager is an integral part of NDPS and provides a platform on which to run Printer Agents. The third-party gateway is provided by the printer manufacturer for a specific printer or class of printers.

Printer Agents (unless embedded in the printer itself) are created to run on the NDPS Manager to front-end printers which do not contain NDPS capabilities and make them appear to users and administrators as full NDPS printers. The NDPS Manager uses NDPS to communicate with users and administrators on one end, but requires a gateway to communicate with the printer on the other.

Some printer manufacturers have developed proprietary mechanisms for dynamically discovering their printers and for providing comprehensive access to their printers' capabilities. Gateways developed by these printer manufacturers can be snapped in to the NDPS Manager to give NDPS administrators and users enhanced access to the intended printers.

Different levels of NDPS functionality are available depending upon the actual implementation of a specific gateway and the capabilities of the protocols used by the gateway.

Using the Novell Gateway. For legacy printers that are not supported by third-party gateways, NetWare 5 includes a generic Novell gateway that allows the NDPS Manager to communicate with legacy devices using the LPR/LPD protocol on IP or the RP protocol on IPX, LPT, and COM ports, as illustrated in Figure 2.

Figure 2: NDPS configuration designed to function with the Novell Gateway.

Using the Novell gateway, jobs can also be written to a queue as a way to route them to a different print system or to network printers set up in QServer mode.

By printing through the Novell gateway, your printers have support for Pure IP via LPR and support for IPX, as well as some feedback and control. Disadvantages of using the Novell gateway include manual configuration of Printer Agents and limited printer information availiability.

Option 2: Using Printers with Embedded NDPS Technology

As NDPS-embedded printers become common, this option will become the optimal configuration and provide the most powerful NDPS capabilities, offering true plug-and-print capability and exceptional feedback and control for users and administrators.

Figure 3: NDPS-embedded printer configuration.

With an embedded NDPS configuration, administrators and end-users can directly interact with print devices. This configuration is possible because the printers have an embedded NDPS Printer Agent, as illustrated in Figure 3. Several printer manufacturers are working to embed NDPS into their next generation of printers.

NDPS Printer Agents Printer Agents are the very heart of NDPS. They combine the functions previously performed by a printer, print queue, print server, and spooler into one intelligent and simplified entity. Printer Agents are the NDPS component that receive and process NDPS printer and job requests and provide a standard interface to all NDPS users and administrators regardless of the type of printer they represent.

Option 3: Maintaining Existing Configurations

This configuration of using print queues, as illustrated in Figure 4, is the most common print system used in the NetWare 4.x. Because NetWare 5 continues support for legacy printing, no configuration changes to your existing print system are necessary when you upgrade your operating system to NetWare 5. Other advantages to maintaing your current printing configuration include support for all NetWare 4 clients (however, any client released after vorder services will support NDPS) and support for clients not directly supported by NDPS (UNIX, Macintosh, OS/2, and DOS). The primary disadvantage is that your users printing through queues won't enjoy the advanced features and convenience of NDPS.

Figure 4: Common printing configrations in NetWare 4.x remain compatible with NDPS running on NetWare 5.

NDPS Planning Issues

The transition to your new printing system will go much more smoothly if you identify the major issues involved before you begin the process. The NDPS product management team suggests that you develop your own checklist of issues, using the following ideas as starting points.

Determining Which Protocol(s) to Use

The most prominent feature of NetWare 5 is its support for operating in a pure IP-based environment. NetWare continues to support the IPX protocol but gives you the option of choosing which combination of IP, IPX, or both that you implement. This choice in protocol implementation greatly determines your printer configuration in NDPS.

Deciding which protocol(s) to use may also be determined by the printers already on your system, the availability of third-party gateways for those printers, and the printing needs of your users. Below are several popular printing configurations with suggestions to help you plan for NDPS migration.

In NetWare 5, NetWare Core Protocol (NCP) communication can travel on top of IPX or on top of IP in a Pure IP configuration (where the IP NCPs are no longer IPX packets encapsulated inside IP). In NetWare 5, all applications that use NCP and do not interface directly with IPX or SPX can operate as Pure IP applications.

NetWare 5 also supports existing applications that directly access IPX-based protocols (make IPX/SPX or SAP calls) through its Compatibility Mode. Compatibility Mode is implemented as a set of system components that allow IPX client or server applications to locate and communicate with their IPX counterparts without IPX packets being visible on the wire. Compatibility Mode components translate SAP advertise and query requests into their SLP equivalents, allowing IPX applications to dynamically advertise and/or discover without generating IPX traffic on the wire.

All NDPS components are IP-aware and IPX-aware, so they do not rely on Compatibility Mode to implement IP-based communication.

Determining When to Upgrade Clients

If you have a fairly large number of workstation clients, you may find it inconvenient to try to upgrade them to NDPS all at once. Because NDPS allows you to implement all of the server management components while allowing your workstation users to continue to print to queues just as they always have, you can upgrade these clients at a pace that suits your needs while you take advantage of the management benefits NDPS provides immediately. (Look under the heading below titled, "Making the Transition Gradually" for more information.)

Network Printing Security

NDPS is tightly integrated with NDS to maximize both the security and ease of management that NDS provides. The level of security you desire for each of your printers can be as flexible as you want it to be, ranging from total public access to tightly controlled access. Printer security for controlled access printers is ensured through the assignment of the Manager, Operator, and User access control roles.

Distributing Brokered Services

While the distribution of your Brokers is not really a critical issue initially, you will probably want to give some thought to this issue as you do your preliminary planning. You will not need to create a Broker on all of your servers, but you will want your Brokers sufficiently well distributed so that your brokered services (Service Registry Service, Event Notification Service, and Resource Management Service) will be readily available on the system when needed. The Broker(s) created automatically during the NetWare 5 installation process will be sufficient to implement you new NDPS system successfully, but as you gain experience with your new system, you may want to add or delete Brokers to optimize the efficiency of your system or to store your brokered resources (maintained in the Resource Management database) where you want them.

Designing Your New System

As a final planning step, before you begin the implementation process, you should create a written record of all the network resources and components that will be incorporated into your new printing system (printers, servers, workstation clients, routers, and others). Then, you should draw a diagram of how these components will fit together in your modified NDS tree.

You should first make a record of your printing resources. Write a list that you can refer to as you make a diagram of your NDS tree. This record helps you include all of the printing resources you need for your network when you start to create the NDS objects. For example, you might record that you have two printers for one location on your network. One will be used for everyone in the office, and the other is used only by the production team. This information can guide you in creating your diagram.

Then create a diagram of the new NDS tree. You should create a diagram of the printing layout you want to implement in your new system. The diagram will help you simplify and reorganize your setup. The diagram you create can take a variety of forms: drawing a tree diagram is the most common. You can also create a list that includes all of the objects that will be in the tree, or you might prefer to create an organization chart with responsibilities and resources listed by each name.

The diagram should be centered around the printers and the NDPS Manager. (Keep in mind that only one NDPS Manager can be loaded on a server.) Although there are other items that may be included in the diagram, such as the NDPS Broker, printer Users, Managers, and Operators, or printer configuration information, the printers and the NDPS Manager are all that is necessary at this stage. Place the printers in the appropriate areas. Create an NDPS Manager on the server that you want to handle the Printer Agents that correspond with those printers.

Determining Your Implementation Strategy

Now that you have done some initial information gathering, identified the major issues you will face, and created a diagram of the new NDS layout you want to implement, you can now consider your strategy for implementing your new or upgraded system.

General Transition Guidelines

The following guidelines generically apply to any transition scenario and should expedite your decision process.

As we discussed already, third-party gateways are currently the best option for printers they support. Until NDPS-embedded printers become widely available, third-party gateways allow the fullest access to networked print devices. So, when migrating a printer to NDPS or when installing a new printer in an NDPS environment, you should first determine the availability of a third-party gateway for that printer. If a gateway is available and it supports your system's environment, the third-party gateway should be your first choice. Also, make sure your particular gateway supports the communication protocols you plan to use in your network.

NDPS provides simple and reliable configurations for Pure IP environments. If a third-party gateway capable of Pure IP is available for the printer being configured, it should be used. Otherwise, use the Novell gateway and configure it to communicate with the printer using the LPR protocol. Before doing so, however, make sure the printer is configured for LPR/LPD and has an IP address assigned to it.

As you implement NDPS, migrate the server side first, then migrate your end-users gradually. A sensible approach to deploying NDPS into a system is to first replace the server components of your legacy printing system with the NDPS server components. Since the NDPS Manager (NDPSM.NLM) and the Print Server (PSERVER.NLM) can run simultaneously on a NetWare server, this transition can be accomplished one queue/printer at a time. Users can then be gradually switched to print directly to NDPS printers, replacing your queues. This transitional configuration is illustrated in Figure 5.

Figure 5: Gradual migration configuration from queue-based printing to NDPS.

Note: Eventually, only a few queues serviced by NDPS Printer Agents will remain to support your DOS and Windows DOS-box printing needs, while most printing will be done through the basic NDPS configuration and its variations, as explained above in "Option"1: Using Legacy Printers and NDPS Gateways".

Making the Transition Gradually

If you are currently using a queue-based printing system, you can continue to use your existing system without modification. Because of the advantages provided by NDPS, however, we recommend that you begin the transition as soon as it becomes convenient.

In general, it is best if you make the move to NDPS gradually. Begin by implementing the NDPS server components and management features available through the graphical NetWare Administrator utility. This strategy allows you to set up your new printers and optimize the distribution of your brokered resources while your end users continue printing through the same queues they always have. Then, when you are satisfied that your NDPS printing components are set up and configured the way you want them, you can begin upgrading your end users to the new system gradually.

Maintaining Your Queues During the Transition

NDPS Printer Agents, either embedded into printers or running as part of an NDPS Manager, can be configured to retrieve jobs from queues in addition to accepting jobs from NDPS users.

Maintaining your queues allows you to gradually migrate users to NDPS because users' workstations can continue to print to existing queues and be moved to NDPS as time permits. Workstations can even be configured to print to both queues and NDPS printers.

In addition to allowing for a gradual transition to NDPS, this configuration is also the only support currently available for DOS and Windows DOS-box printing and for handling printing requests from other systems such as UNIX or Macintosh. It also allows NetWare 4.x clients to submit jobs to NetWare 5 queues, providing these clients with access to NDPS-managed printers.

After you have created NDPS Printer objects to represent the printers that are still servicing queues, you can delete your legacy Print Server and Printer objects (but not your Queue objects) if you wish, reducing the number of objects in your NDS tree you need to manage.

In most cases, you will want to upgrade your administrators' workstations to NDPS first because NDPS allows administrators to quickly benefit from its advanced capabilities such as automatic printer driver download, extended job management, and event notification.

Note: Be sure that the Adminstrator's workstation has the latest version of the client installed. (On a Windows 95 machine, you need to have Windows 95 Service Pack 1 installed, which can be downloaded from Microsoft's web site.) In our tests in the lab, we could not setup NDPS from a workstation running Windows 95 without first installing the service pack. However, a workstation running Windows 98 performed the same tasks without incident.

Administrators can accomplish much of the migration remotely by removing the CAPTURE statements from users' login scripts and installing NDPS printers on their workstations using the NDPS Remote Printer Management functionality, once the workstations are running the NDPS client.

Using Compatibility Mode to Maintain Existing IPX-Based Configurations on IP

It is possible to keep existing printing configurations while converting the bulk of a network to IP. You can do this by using the NetWare 5 Migration Agent to help implement Compatibility Mode, as shown in Figure 6.

Figure 6: Using the NetWare 5 Migration Agent to implement Compatibility Mode

Through the Migration Agent, IPX segments can be easily isolated in an IP network, or if preferred, IP segments can be easily isolated in an IPX network. The Migration Agent allows IPX applications running in IPX segments to advertise/discover and communicate with IPX applications running on NetWare 5 clients or servers in IP segments while keeping IPX traffic hidden in those IP segments.

All IPX applications running on NetWare 5 clients or servers can benefit from the Compatibility Mode's encapsulation and translation capabilities. IPX-based printers cannot directly benefit from this encapsulation/translation, however, because they don't execute on top of a NetWare 5 server or client, and their communication cannot be intercepted before it goes on the wire. Such devices must reside in an isolated IPX segment and rely on a Migration Agent to cleanly redirect their communication in and out of IP segments.

Migration Scenarios

The following migration scenarios will help you better understand the process of making the transition to an NDPS environment that will best meet your printing needs.

Migrating from Queue-Based Printing to NDPS

Most queue-based printing in NetWare networks is currently realized through one of the following configurations in Figure 7.

Figure 7: Common queue-based printer configurations.

When migrating to NDPS from any of these configurations, you should first consider using a third-party gateway. The protocols, connection methods used, and potential need to configure the printer depend upon the particular gateway used.

For printers for which a third-party gateway is not available, the Novell gateway provides a straightforward configuration path. The NDPS configurations corresponding to the queue-based printing configurations illustrated above, as well as an additional configuration for Pure IP support, are shown below in Figure 8.

Figure 8: Possible NDPS configuration scenarios, corresponding to the queue-baseb confiugrations in Figure 7 above.

The NDPS configuration (1) above is not recommended because a back-end queue is still required, increasing network traffic and delaying job completion. In addition, while transitioning to NDPS, there would be two queues in the print path as shown in Figure 9.

Figure 9: This configuration is not recommended because of the increased traffic caused by multiple queues required to service the same printer.

If you are migrating a QServer-mode printer, we recommend that you reconfigure it for LPR as in configuration (5) or RP as in configuration (2) if possible. Choose configuration (5) if the network supports IP and the printer supports LPR/LPD. Choose configuration (2) if the network supports IPX and the printer supports RP. Configurations (3) and (4) are available if the printer does not support LPR or RP, but you still wish to benefit from many NDPS features without the need for a queue. Notice that configurations (2) through (5) require you to configure the print device to enable a new protocol.

Notice that if the NPRINTER.EXE in configuration (3) is running on a NetWare 5 client, it is possible to realize IP-only printing to a remote printer, though not Pure IP. However, if IP is desired, configuration (5) is preferable and is Pure IP.


NetWare 5 dramatically improves network printing services by offering NDPS as the default print system. With implementation flexibility and native support of IP, NDPS offers more choice in determining the printer configuration that best fits your organization's needs. Through careful planning and evaluation, your move to NDPS will prove advantageous in the short term with the ease of install and in the long term with the ease of management and maintainence.

To learn more about future plans for NDPS and to stay current with third-party developments for NDPS printers, visit the web site at:

* Originally published in Novell AppNotes


The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates