This chapter focuses on providing an overview of computer networking as it is implemented on Windows NT. As mentioned in the last chapter, networking is an important built-in feature that Windows NT provides both for itself and for other BackOffice
components. Because all BackOffice components are extremely dependent on networking, this is a very important feature. Because there are so many different types of networks that are common in modern business environments, it is important to understand all
the options that Windows NT provides so that you are ready at implementation time.
This is also an important topic to get under your belt before you begin the server planning exercise in the next chapter. Many of the decisions that you will have to make are relatively straightforward (do you need a database management system or a Web
server, for example). The network decisions that you will be asked to make are a little tougher. For example, the decision on whether to install a particular network protocol or service depends on your application plans or the needs of another dependent
network service. Therefore, you need to be at least familiar with the ideas of computer networks, if not comfortable with them.
PC-based local area networks grew up somewhat differently than their mainframe, minicomputer, and larger server cousins, and this has some effect on where they are today. The earliest PC networks were built to share expensive resources, such as
printers, with one another. They also provided the capability of sharing files. They were not asked to perform cooperative processing between applications or provide convenient directory services.
Based on these rather simple needs, many early networking standards evolved. NetBEUI was among these early standards. It is important to consider when it was designed when we look at these utilities today and note their limitations when it comes to
modern uses. For example, NetBEUI is a somewhat limited and problematic protocol to use if you are implementing client-server database connections. It was never designed for that purpose. It also is not designed for routing between networks.
This section challenges you to think about what you are asking a network to do for you. Although this list could go on for pages and you might think up some unique needs that you have come across, here is a list to start you off:
I'm sure that you can come up with some additions to this list. However, it should get you started thinking of the functions of a network. The designers of Windows NT and networking in general have thought through this list and come up with a number of
products and standards that can be used to meet these needs. As with many things in the computer industry, you are blessed with a wealth of alternatives, and the challenge comes down to determining which alternative to choose. The section after next
discusses these options to help you with your decisions.
Before you get into the network details (at least the level of details that you can get into in a single chapter), let's explore how applications interface to the network. If the NT networking utilities provided service only for Windows NT, they would
be of little use. To leverage their investment in networking technology to the large number of applications that are available, Microsoft has published a number of standard APIs that enable developers to use the services of the network. The most common use
of networks by applications is accessing the file and print services that are provided by the operating system. However, there are an increasing number of applications that use more sophisticated interfaces that transmit data between programs or even use
functions of applications that are running on one computer directly in an application that is running on a different computer. The key from an administrator’s point of view is understanding which of the many forms of interface were used in your
applications (for example, SQL*Net from Oracle, which interfaces directly to the TCP/IP, IPX/SPX, and NetBEUI protocols) and what that requires from you in terms of support.
Let's start by going over what makes up Windows NT’s integrated networking. Previous chapters have covered some of the technologies at the technology level (such as Netware services and FTP). This section is devoted to presenting an integrated
picture of the networking components and how they fit together. Perhaps the easiest way to start this task is with a picture (see Figure 8.1).
FIGURE 8.1. Windows NT networking overview.
You need to understand these components and how they fit together before you can start configuring your network. The basic goal is to get data from a user application (such as Explorer or a client-server database application that you develop locally) to
the networking wire running out of your machine. For purposes of this discussion, I divided the networking hierarchy into three components:
The key to connecting workstations together for network communications is standards. Of course, the industry has a number of players who think that they are, by definition, the standard. (I am not just talking about Microsoft.) Therefore, your ability
to connect to other workstations is limited by the standards that your computer supports. Fortunately, Windows NT supports a wide range of computers through its built-in networking protocols and services. Because almost everyone is building operating
systems that connect to the Internet, TCP/IP is the most common communications protocol in use today, and Windows NT supports it as part of the standard delivery (no extra products or options to buy).
Therefore, before you go into the actual configuration procedures for Windows NT networking, it might be helpful to review the list of options that you have that relate to network standards. These standards include not only the protocols that you will
use to configure your network, but also several interface standards that will enable applications that you purchase to interface with the NT networking services to communicate with remote systems:
Working with the standards listed are dozens of other lower-level items, such as the Ethernet and token ring transmission standards associated with a given network card. However, for purposes of this discussion, the preceding list can be thought of as a
basic laundry list of services that you would install under Windows NT networking. These standards make it easy to integrate Windows NT servers and workstations into existing networks. This is especially true of the Netware connectivity and TCP/IP (hence
UNIX) connectivity components. You might still have to work out the details of the connection, but it is a good start to know that communication is possible and relatively easy in the NT environment.
Many of the acronyms in this chapter end in the letter P, which usually stands for protocol. I like to think of a protocol as an agreed-upon standard that ensures that I can communicate my information with others. This section focuses on a specific set
of protocols that determine who can receive your signals on the network. These transmission protocols set standards that enable computers on the network to determine whether the packets are intended for them and then determine what should be done with the
information.
There are entire books devoted to the details of these protocols from SAMS, and the Windows NT Networking Guide in the resource kit provides more detailed discussions on protocols. I have chosen to focus this section on providing an overview of these
protocols that covers the information that a system administrator (not a network engineer) would want to see:
Let's start with a discussion of TCP/IP. What is it that makes TCP/IP an important protocol for today’s system administrators? It is the protocol that drives the Internet, for one thing. It is also a protocol that can be routed (signals sent only
to those network segments that need them as opposed to being broadcast throughout the entire network), which keeps overall network traffic loads down. It is also a robust protocol that incorporates transmission reliability features and a capability of
interfacing applications to sockets for specialized forms of communications (that is, FTP or client-server database communications).
The TCP/IP protocol was originally developed by the United States military and it was soon adopted by universities and other government agencies as a standard. A large boost came when the Berkeley UNIX world started to emphasize networking and adopted
TCP/IP as its standard. Over the years, the Internet, and its protocol suite, have developed a sort of life of its own. There are working groups composed of industry experts and concerned users who are working to evolve the standards to meet the new
requirements that are ahead. An example of this is the work being done to address the issue of the rapid expansion of the Internet, how additional addresses can be made available, and how to improve traffic routing.
Recall that the acronym TCP/IP stands for Transmission Control Protocol and Internet Protocol). My rough distinction between these two is that TCP handles the details of the message, and IP provides a means to provide an easy to use and route address
for each computer. There are a number of other standard supporting protocols that are grouped into the TCP/IP family in common practice. Examples of this include Ping to see whether a remote server is responding to the network or FTP to transfer files
between computers.
From the system administrator’s point of view, the pros and cons of this protocol include the following:
NetBEUI sort of falls at the other end of the spectrum in terms of standardization and robustness. Windows NT uses the NetBEUI Frame (NBF) protocol, which is an extension of the old NetBIOS Extended User Interface (NetBEUI) protocol. IBM introduced
NetBEUI in 1985 to support its PC network communications. It was intended to be simple and optimized for simple network functions, such as printing and file sharing, which are common to PC networks. NBF’s main enhancement is that it enables you to
have more than the 254 sessions that are permitted under NetBEUI.
When NetBEUI was invented, this seemed a very reasonable limit for local area networks. A more telling limitation is the fact that NetBEUI was not designed to provide reliable connectionless communications. The Windows NT Networking Guide provides an
interesting discussion of this topic, but it basically means that it does not get a confirmation that the message has made it to the sender. This is not a big problem for a print job (if you do not get your printout, you resend it), but it could be a
severe problem for a large financial database transaction sent over the network.
The summary of pros and cons, as viewed by system administrators, of NetBEUI include the following:
IPX/SPX is the protocol suite that forms the basis for the majority of Novell Netware installations that are available today. Novell has recently provided you with the option of using TCP/IP for your Novell network. Recall that IPX stands for
Internetwork Packet Exchange. It is designed to have a low overhead and is optimized for local area networks. SPX (Sequenced Packet Exchange) functions like NetBIOS for IPX/SPX networks. It is connection-oriented (both sides talk to one another about the
transmissions they are making).
As with the previous two protocols, there are books on the subject that can take you into the details of the packets, addressing, and so forth. However, the key points to take away from this chapter about IPX/SPX are the following:
As with most Windows NT components that are integrated with the operating system, networking is configured using the Control Panel, which can be accessed with from the My Computer desktop icon or from the settings option of the start menu. As you can
see in Figure 8.2, there are a number of Control Panel icons that relate to networking: FTP server, modems, ODBC, services, and the one that we are interested in for this chapter—Network. This icon is the key to setting up your networking
functionality, and you need to complete this setup before you can set up the other functions.
FIGURE 8.2. Windows NT Control Panel and Network icon.
When you double-click on the network icon, you are presented with the new Windows NT 4.0 setup panel (see Figure 8.3). Based on my observations of Windows NT 4.0 and Windows 95, Microsoft seems to be moving heavily toward the tabbed
dialog interface for configuring items, so it would be useful for you to get comfortable with this interface. It is relatively simple to work with; there are a number of tabs across the top, each of which corresponds to a data entry or display panel with
which you need to work. The items that are being configured are listed in a window similar to the one showing network adapters in Figure 8.3. The plus sign indicates that if you click the icon, you will get an expanded list of items that are associated
with the item that you just clicked (an expanding list). Finally, there are a series of buttons (such as Add, Remove, and Configure) that enable you to perform the allowable actions on the list.
FIGURE 8.3. Network setup panel.
The tabs correspond to the items in the hierarchy discussed earlier in this chapter. In this case, you build your network from the bottom up, starting with the adapters. Next, you select the protocols and then the services. To connect this all, use the
Bindings tab dialog. Finally, an identification tab enables you to specify how your computer is identified on a Microsoft network. Each of these tabs builds on the others to form the complete network picture, so you have to work with all of them to set up
your network.
When you set up networking, you are probably going to have to reboot your computer after you finish entering the new settings. This is because networking is tightly integrated into the operating system itself. At the end of the setup, you will receive a
prompt that asks whether you want to reboot the system now. I like to choose a time when I can do the reboot immediately after my work so that I can check to see whether everything went okay. (A little mistake could deactivate your client-server database
connection, for example.) As another example, if I clicked the wrong button (Yes) when prompted for the reboot, the system would shut down and restart. Therefore, I do not do this work on a production server during production hours. Users of a
network-based computer system get really sensitive when their server is down unexpectedly.
One of the features that some people were hoping for in Windows NT 4.0 was what Microsoft and others refer to as Plug and Play. Unfortunately, that will not be completed in this release. Under Windows 95, the system has a reasonable chance of
recognizing the existence and type for a large number of cards and peripherals that you might connect to your system. It will then take you through a series of wizards to set things up correctly (you hope). It is not perfect, but it makes life much easier
when it works.
Under the 4.0 version of Windows NT, you still have to manually tell the operating system what components you have installed. Therefore, you start the networking section with the network adapters. You might be thinking that Windows NT 4.0 is more like
Windows 95. Even though modems are part of networking under Windows NT, they do not show up as a network adapter the way they do under Windows 95. However, you will find bindings to the RAS wrappers later in the network setup, so RAS is not a totally
separate subsystem.
Let's look at the options in the Adapters tab on the Network Setup panel (refer to Figure 8.3). As you can see, it lists my network adapter. It lists multiple network adapters and enables you to configure each of them individually. If you add a new
adapter to your system, you click the Add button on the Adapters tab of the Network Setup panel. NT then presents you with a list of adapters that it supports (that are distributed on the Windows NT operating system CD) and enables you to choose one of
them, as shown in Figure 8.4. This list is not very long when compared with that of Windows 95, for example, so it is important to check that your adapter is supported by Windows NT before you buy it. If it is not one of the ones that Microsoft
provides drivers for on the NT operating system CD, you can use the Have Disk button to enable NT to read a disk or CD drive that contains drivers given to you by the manufacturer.
FIGURE 8.4. Select Network Adapter dialog box.
Once you select the adapter that you are going to use, you need to configure it. Here is where all that hardware stuff can be a challenge for an operating system type who just wants to get things up and running quickly. The various adapter manufacturers
have different ways to configure an adapter. Some use jumpers located on the card itself, others use software utilities that will enable you to set it up programmatically. Whatever the method, you may have quite a challenge in front of you to select
settings for this network card that do not conflict with other hardware components that you might have installed, such as serial ports, drives, or sound systems.
There are two key addresses that you need to worry about when setting up an Intel-based machine, which is the most popular platform for NT by far. The first address is known as the IRQ level, which is also referred to as the interrupt number. It is one
of 16 addresses that are available to get the attention of the operating system at the hardware level. You may think that 16 is a lot of addresses, but the machine that I am typing on has all 16 addresses used up between network cards, modems, a sound
card, and the motherboard itself (which takes up 4 or more addresses before you put the first card on the system). The next address is usually referred to as the I/O port address. It is a section of the memory of your computer that is used for transferring
data from the various installed cards and components.
When you buy workstations based on the MIPS or Alpha architectures, they usually have fixed addresses for their various components, and your task is to figure out what these standard addresses are and just use them. The unfortunate part of the Intel
world is that the operating system fixes a couple of addresses for such things as the system clock and then throws the rest up for grabs—with only some suggestions as to what should be used for what purpose. To make matters more complex, certain
peripheral devices support only a few of the many possible combinations of IRQ and I/O port addresses. You need to have this worked out before you start working on your server or schedule plenty of time to try out all the possible combinations. Finally,
don’t feel bad if it takes a while. I have found several machines that, no matter what combinations we tried, we could not make certain components work. We had to replace them with others that were more compatible with the other components in the
system.
The NT Diagnostics tool on the Administrative Tools menu can provide some insight into the resources in use by your computer.
Let's return to the actual configuration task itself. You will be asked to set the addresses and possibly some additional configuration parameters for the adapter that you have chosen. You may choose poorly and be informed that your networking services
did not start up because of some addressing conflict. You task is to then adjust the settings of your adapter card, both through its jumper settings or setup utility and through the Network Setup panel. On the Network Setup panel, you select the Adapters
tab and then choose the Configure button. You are presented with a panel similar to Figure 8.5, which enables you to alter the settings.
FIGURE 8.5. Network adapter configuration settings.
Perhaps you have gathered from the tone of my writings that this can be a very frustrating part of setting up a system. I can always tell those in my group who are setting up the hardware on a computer system, because they stare intently and furiously
at the monitor—or yell at their systems (I dread the day when they yell back). There are a few tips that may help when you are trying to get through the installation and configuration of hardware:
After that, you’re working a puzzle to see whether you can get all the pieces to fit together.
The next step in configuring your network is to decide which protocols you need to support. Usually, you will have these dictated to you by corporate standards, places you need to connect to, and so forth. There are a few general suggestions for you to
consider when deciding:
To set up protocols in your system, you will use the Protocols tab on the Network Setup panel (see Figure 8.6). The nice thing that you will notice is that it looks very similar to the previous Adapters tab. That is the real benefit to this common
interface for properties settings. Basically, you have to add protocols from the list of available protocols (you can even add protocols from third-party manufacturer diskettes, but I have never had to use more than what is provided on the NT distribution
CD). The complexity comes in when you configure the protocols. NetBEUI is relatively simple to configure and IPX/SPX usually works with the minimal default settings (see Figure 8.6). However, TCP/IP usually requires some work to get running properly.
The reason that TCP/IP is so complex to set up comes from some of its ambitious design goals. It connects millions of computers worldwide through a logical network made up of many thousands of other networks. To make this all work together, software and
hardware vendors have built up a scheme started by the United States military that enables you to map the hardware address (the ethernet address, which is a set of hexidecimal numbers assigned by the network card manufacturer) to a set of numbers that
correspond to your organization (the Internet address or IP address). Therefore, the first key to remember is that an IP address is your key to getting on the Internet, and therefore all the TCP/IP software is designed to work with this address (even if
you do not plan on surfing the Internet).
Figure 8.7 shows you the panel that will pop up when you configure TCP/IP. It is far more complex than the protocol setup panel and also requires that you understand a little about the fundamentals of TCP/IP systems before you can answer all the
questions. There are a number of considerations that you use in making your decision, but here are a few of the more common ones:
FIGURE 8.7. Configuring the TCP/IP protocol.
Suppose that you want to keep things simple and get a basic TCP/IP network up and running. You do not plan on getting on the Internet. What I usually do is specify an explicit set of IP addresses similar to those shown in Figure 8.7 (the 10.x.x.x
family is reserved for internal assignments). I set the simple subnet mask of 255.0.0.0. I then set up a special file used by most TCP/IP configurations known as the hosts file (which is a local file that resolves names to addresses similar to the WINS and
DNS servers).
Let's look at a sample hosts file. It is a simple mapping between an IP address and a name that is easier for people to type. As you can see, it would be impossible to maintain this table for the millions of people on the Internet, but it works well in
small workgroups. You need to place this file under your Windows NT directory in the system32\drivers\etc subdirectory. (Mine is in d:\winnt35\system32\drivers\etc because I upgraded to 4.0 from 3.51.) This file should also be distributed to all clients so
that they can work with these easy names:
# ****************************************** # # File: hosts # Purpose: Capture TCP/IP Configuration # # Revisions: # # 9/1/96 File created (Joe Greene) # # ****************************************** 127.0.0.1 localhost jbgreene 193.9.12.13 BIG_SERVER 193.9.12.45 SMALL_SERVER # ****************************************** # END OF FILE # ******************************************
There are a lot of additional considerations with TCP/IP networking. The key to remember is that every computer that is running on a TCP/IP network at a given time should have a unique IP address. When this type of network is set up
correctly, it runs well and provides you with connectivity and service that is hard to beat.
You can run into severe addressing problems if you do not get a unique, officially assigned IP address and you connect to the Internet. Your Internet Service Provider should be able to help you to contact the correct addressing authority.
So far, you have laid the foundation for networking, but you do not have much that is useful to the end-user. For those of you who labored hours to set up a working IRQ setting on your network card, this may not seem fair. However, now you get to
install the services that will enable your network to be used by the end-users to get things done. I have found the services to be relatively simple to set up and configure once the networking basics are out of the way. You start with the Services tab of
the Network setup panel (see Figure 8.8).
FIGURE 8.8. Network Services setup.
To add to the services that you have installed, choose the Add button. It gives you a list of available services and the option of adding additional services from separate CDs or disks (the magic Have Disk button). The most difficult task is
understanding what services are available to you (and there is quite a list of services that come off the operating system CD):
Many of these services are just installed. There are no configuration chores that you have to perform on them. Those that do require some form of configuration are presented with a panel similar to Figure 8.9 that is specific to that particular service.
FIGURE 8.9. Remote Access Setup panel.
As you can see, there is a wide range of services available under Windows NT. The key to something that is implemented as a service is that it will be a background process that is in continuous operation once started, which usually occurs at system
startup. Therefore, it is available even though there are no users logged in at the console and running programs. They are essential to Windows NT server 4 being able to serve clients on the network.
After the long discussion of options when setting up TCP/IP networking and the many services available under NT server, it is refreshing to see a relatively simple tab on the Network setup panel—the Identification tab (see Figure 8.10). This tab
sets what other computers on the Microsoft network will see when they are looking for computers. The key components are Computer Name, which is just a unique identifier for the computer that should make sense to everyone else in your workgroup or domain.
The next box for workgroups is your workgroup name. (You are asked to identify your domain if you chose the Domain option when setting up your Microsoft network.) The workgroup and domain names are names made up by administrators to refer to a particular
group of computers. In the domain environment, it has special meaning in that you can teach domains to trust one another and grant privileges to members of other domains. If you are looking for a more detailed discussion of domains and workgroups, the
Windows NT Networking Guide in the resource kit provides some good material.
FIGURE 8.10. Network Identification.
So far, you have explored the various options that are available when you set up networks. Now consider the possibility of setting up multiple network adapters and remote access services that use different sets of protocols and services, and perhaps
even different configuration parameters for those protocols and services. It may seem like an unusual setup to some, but I have run across several examples of this being needed. A classic example is a server acting as a gateway between two network
segments. You may have Novell and TCP/IP machines on one side, which your network administrator has assigned the IP address range of 123.123.1.xxx. The other network segment might have Microsoft networking (NetBEUI) and TCP/IP clients, but they use
the IP address range of 123.123.2.xxx. In this manner, you can isolate and balance network traffic between different network segments. You use the adapter configuration tab to set up the IP addresses for the two adapters, but you then have to use
the Binding tab (see Figure 8.11) to configure which protocols went where.
FIGURE 8.11. Network Bindings.
There are three ways to sort the list of bindings. The one that you choose depends on how you think of things and what problem you are working on. As you can see in Figure 8.11, I have linked the TCP/IP protocol to my network card and the Remote Access
Server. If I wanted to remove this connectivity or add in additional connectivity, I would use the Enable and Disable buttons. Be careful where you are when you start disabling bindings. The key is knowing what protocols, services, and adapters depend on
one another to ensure that you do not disable other things that you want when you disable a particular binding.
Under Windows 95, dial-up networking (the modems) is considered an integral part of networking and is set up pretty much the way you set up any other adapter. Of course, the modems have their own property pages that take into account the unique setup
parameters of a modem (all the bit settings and whether you have to display a terminal screen before and after dialing a number). Windows NT 4 server has not quite embraced this philosophy yet. Although you do bind the network wrappers (between the
computers connected with the modem to computers connected via your network cards) using the network setup panel, you do most of your other work setting up these connections using the Modem option on Control Panel. The actual modem connections and privilege
setup (who can dial in, for example) is set up through the Remote Access Administration utility accessible from the Startup Menu, Programs selection, and Remote Access Service selection (see Figure 8.12).
FIGURE 8.12. Accessing the Remote Access service utilities.
The first thing that you need to set up RAS is to have a modem properly configured. This might involve some of the same painstaking work described previously for network adapters (such as getting drivers loaded for your modem and resolving IRQ/memory
addresses). Figure 8.13 shows you the basic modem setup screen. You have to add a modem type that is supported by Windows NT 4 (again, see the hardware compatibility list or get an NT 4 driver from the modem vendor). You then have to identify a
communications port to which that modem is mapped (yet another address when dealing with serial communications devices on Intel PCs).
FIGURE 8.13. Modems configuration panel.
Once you have your basic modem set up, you may have two additional panels to set up. The Properties button gets into the communications details (see Figure 8.14) associated with the modem and its connection (speed, speaker volume, and all those bit
settings common to modem communications take the defaults whenever you can on these items). The Dialing Properties button enables you to set up the details of dialing, such as whether you need to dial 9 to get an outside line.
FIGURE 8.14. Modems Properties panel.
Once your modem is set up, you are ready to use the Remote Access Admin utility that is located in the Remote Access Service program group on Windows NT 3.51 and the Administrative Tools Startup Menu group under Windows NT 4.0 and is shown in Figure
8.12. This utility is based on a pull-down menu system that enables you to perform the following useful services:
With the number of people who are accessing networks from remote locations (other groups that you work with or road warriors who travel a lot), RAS connectivity and modem pools are an important part of the Windows NT networking architecture.
After having set up similar functions under UNIX and earlier versions of Novell, the RAS configuration is relatively simple and very reliable. I have set up my home PC to dial in to the server and perform functions ranging from simple file transfers from
my work PC to interacting with client/server databases using ODBC. If you have a modem, take some time to learn how to use it as a remote administrator. It could save you a trip to work in the middle of the night when your server has a few problems.
One of the challenges with working and providing services in a network environment is that most users see only the end result. For example, they install new client-server applications on their PCs and complain that they can’t access the database
that is on your server. What is the problem? (I can’t tell you how many error messages read something like, "I couldn’t talk to the server.") Recall that the many layers and bindings involved have to be set up correctly on both ends to
make communications happen. You also have to worry about logon IDs and passwords being set and used correctly to provide access to resources that are password-protected.
With all the things that can go wrong, I like to follow some basic checks from the client end to troubleshoot problems.
If anyone has trouble accessing the server, you can try it from your workstation using the My Computer icon or File Manager. (Note that File Manager and Explorer enable you to enter explicit network paths that may be available, but somehow the network
browsing function does not detect when you look at the available nodes.) You can also use the NET VIEW command at the command prompt (NET VIEW \\joe, for example). This proves the server is up and accepting at least NetBEUI communications.
If you are troubleshooting a TCP/IP link from the user workstation, go to the DOS prompt and type ping followed by the IP address of the server. If this works, you can try the ping command with the name to see whether your problem lies in the name
resolution process. Together, these utilities test the basics of TCP/IP networking on the server.
The tools that are available depend to a high degree on your environment. However, if you keep the fundamental principles in mind and start testing the various types of communications from the lower levels (such as ping and File Manager) and then work
your way up in the chain (such as ODBC connections or trying to access a shared directory using the user’s logon ID and password), you can usually spot the problem. If all else fails, try doing the same things using the user’s logon ID from a
similar workstation in the same area and see whether that clears up the problem.
This chapter covered a lot of information in a short span of pages. It showed you the broad range of networking functions that are built in to the Windows NT operating system. Coming from older environments where everything costs extra, it is impressive to look at this list of standard features. These features are made available to your applications, especially the network-dependent BackOffice suite, to enable them to accomplish their objectives.
