Many of you may be getting a little impatient to actually start installing software and tweaking buttons on configuration dialog boxes. You have bravely read your way through five introductory chapters that provided some material that you may have
already known. I know how you feel. I often install the software and then read the instructions when I run into a problem. However, I believe that this introductory material is needed for those individuals who are converting to BackOffice from other
computer environments. Many mainframe types are experts on SNA, but may never have seen the protocols and nonbatch operating system concepts that have been presented in this section. Even the Novell folks are probably not used to the wide array of built-in
services and protocols that you find in the baseline Windows NT Server environment (there is a reason that NT is gaining market share so rapidly).
This chapter lays the final set of groundwork before you jump into the first of the BackOffice products (the Windows NT Server operating system). In this chapter, you learn a little background material on intranets. This is a relatively new term in the
computer industry and it's worthwhile to not only go over the product sets, but also to cover the pros and cons of this configuration. Because the term is so new, it is useful to fix the meaning of it as it will be used in this book. It is not really that
strange a concept and can make building an effective in-house network really simple.
An intranet as a network that provides service within an organization that utilizes Internet technologies. There are probably more elegant and precise definitions, but this one should suit your purposes for this book. By this definition, you can qualify
yourself as an intranet if you install any of the following components on one of your servers for use by general users on your network:
This may seem like a relatively simple process, but it shows an underlying philosophical shift that you need to be aware of. Basically, when you set up an intranet, you are moving away from proprietary vendor product suites into a more open product
environment. If your intranet products adhere to standards, you have the option of switching out a poorly performing product for one that provides better performance. You also open up your options later on if you decide to expand onto the Internet or even
provide simple point-to-point links to other organizations that you work with. It will likely be easier to find organizations that support Internet transmission standards than to find those that support the particular version of proprietary electronic mail
that you might have chosen.
For those of you who are moving seriously into the Windows NT environment, you also need to consider Microsoft’s stated product directions. They are not only pushing the Internet, they are also stressing the intranet concept. They have a large
number of products in place to support this environment and a number of others that are slated for delivery in the not-too-distant future. They have even built World Wide Web page interfaces directly into their word processing package. There is no doubt
that Microsoft is serious about this concept.
Another advantage that you should consider if you use Microsoft operating systems on your workstations (that is, almost all PC users) is that Microsoft is bundling tools that interface to the Internet into their operating systems or common utility
packages such as the Microsoft Plus! product. To support organizations, this means that you will have a built-in client available to you that supports Internet mail systems and even Web browsers. If you want to use proprietary electronic mails systems or
other tools to distribute multimedia information, you have to allocate time to install and support these third-party packages.
There are a few other differences between the Internet and intranets that you should consider. The following are the most important:
The Internet backbone uses communications lines that have very high transmission capabilities. This bandwidth is divided among the millions of Internet users, which means that you do not have any guarantee that the bandwidth will be available to you
when you need it. The lines that connect your network to the Internet also tend to be much slower than the main Internet backbone (transmission companies charge for the distance of the connection and the speed of the connection). Figure 6.1 illustrates
these basic issues.
FIGURE 6.1. Bandwidth considerations for intranets and the Internet.
This higher bandwidth allows you to implement technologies that are not quite ready for the main Internet yet. A prime example is digital video transmission from a media server. This would be a very slow process on the main Internet. However, it could
be possible on a moderately loaded local intranet—especially if you implemented 100 Mbps (megabits per second) networks, which are becoming readily available. Other multimedia and bandwidth-intensive transfers are also a possibility using the
intranet.
The next advantage that intranets have over the Internet is security (see Figure 6.2). Perhaps you are not ready to jump into that wild world of the Internet where there are all those hackers, viruses, and scary people. You can isolate your Internet
transmissions with a firewall and provide only controlled access to the Internet. On the safe side of the firewall, you can implement an intranet environment that contains sensitive information that you would not want to have available to outsiders. The
key is that when you have this higher level of security, you have the option of implementing a number of systems that you may not be comfortable implementing in the Internet world.
FIGURE 6.2. Security advantages of intranets.
Another advantage of the intranet is that you will be serving fewer users. A very real concern for those who put interesting content on the Internet is that everyone will want to get at it. There are a number of fairly powerful servers that have been
dragged to their knees when someone puts some content out there that everyone wants. These popular users are often asked to find another server by the system administrator. Therefore, you may want to make your first use of this technology an intranet so
that you can get comfortable with the basic concepts of administration. You also can implement better applications and make more detailed content available when you have fewer users.
The fourth advantage of intranets over the Internet is that you will probably have a more homogenous user environment to deal with. Your corporate standards will probably limit you to one or two Web browsers, a common electronic mail package, and so
forth. It can take quite some time if you are trying to support users who are using a wide variety of applications to access your Web site. For example, how do you help users access your FTP site when they are using a tool that you have never even heard
of? This is especially critical on Web pages, because different browsers support different HTML Web page extensions. On an intranet, you can design your Web pages for the browsers that your users will have on their computers.
The final advantage is that you have better network monitoring with an intranet. Because the Internet is maintained by other people, you are never sure whether your problems are a result of something that you did or something in the Internet that is
beyond your control. The key to exploiting this advantage is to learn to use the network monitoring tools provided as a part of Windows NT server. Chapter 4, "Monitoring Environment," covered the basics of these tools.
You should consider these advantages when you are planning an intranet. My goal in pointing them out was to raise your awareness that an intranet is not some form of poor man’s Internet. It actually has several advantages over the Internet (okay,
the Internet wins when it comes to connectivity to the rest of the world) that you can exploit.
You can build applications for an intranet that the Internet is just not ready to handle at this time.
A few years ago, local area networks were the hot new technology. Today, they are the old tradition that is probably going to be replaced by the newer intranet technology. These differences need to be considered when you are evaluating implementing or
revising your network configuration. Here are the top factors that need to be considered:
The first question that you should consider with regard to intranets versus LANs is how good is your current LAN product suite. The decision to consider new products such as those of an intranet are much easier if your current products are just not
doing the job. Now that people are starting to use electronic mail systems and other such products, the tools that met their needs in the beginning often seem inadequate now. Compare the features of your current tools against those of the newer products to
see whether there are some key features that your users want that are missing in your current products.
Another important consideration is the cost of conversion. You should try to estimate the cost of upgrading your current products. You can then compare that with the cost of purchasing intranet products. Another important consideration that is often
ignored is the labor and training time required for the conversion. You may have to spend a lot of time getting ready to install and support the new products. Conversely, many upgrades to current products also require quite a bit of time as vendors upgrade
their architecture substantially in order to support the more complex features that users are demanding.
The third consideration is expandability. Many LAN products were built in the days of small workgroups of users. This worked fine for a while, but eventually people started to ask about connectivity to other departments. Now the entire organization is
wired together into a LAN environment. Not only has the use of these systems grown as users have come to see their advantages, but cost considerations come into play because it is easier and less expensive to maintain a few larger servers than it is to
maintain a large number of smaller servers. Many LAN applications (such as Microsoft Mail) were designed to support smaller groups of users, and they lack the architecture to take on the larger number of users that are typical of servers today. These
products may need to be replaced in your environment with intranet products that have been designed to support larger user volumes.
You should also consider the cost of supporting LAN applications as opposed to that of supporting intranet applications. Recall that you can usually save money by reducing the number of servers in your environment. This tends to favor the more scalable
intranet products. However, there are costs to retrain people in a new product suite. If the newer product suite is better engineered, you can actually save costs if the interface is more intuitive and there are fewer bugs that you have to help users get
through.
The fifth consideration for intranet products is your need to support product standards. Some products interface grudgingly to the Internet. However, intranet products use the Internet protocols and therefore go smoothly on to the Internet. If you
foresee having to exchange information with others who are already using standard Internet-based products, this may lead you to adopt intranet-based products over traditional LAN products.
A final consideration is whether you want to be on the leading edge or the bleeding edge. Some organizations have to be at the forefront of technology. If your company is into interactive multimedia applications, you will probably have a tough time
implementing your products in a DOS environment. However, it is tough if you just want to get your basic administrative processing work done if you are constantly fussing with new, experimental technologies. Most of the products in the intranet product
suite implemented by Microsoft have been around for a number of years and are fairly well tested. They are leading edge, but also production grade.
You may want to be a little more cautious about implementing some of the bleeding edge technologies, such as Internet phone.
This section takes you through the process of setting up an intranet. It happens to be the first intranet that I set up so it is a real-world example. Let me set the stage for you. There is a group of software developers. We have a couple of servers
running Windows NT Server configured in the workgroup configuration. The main goal is to implement a set of tools that enables developers to communicate with one another and share resources. They have a fair amount of experience as users of the Internet
and are therefore comfortable with many of these tools.
The first thing that we tried to come up with was a list of functional requirements. There was not enough time to conduct a formal study, but the list of requirements that seemed reasonable included the following:
The first requirement that I came across was the electronic mail system. Because the developers did a lot of work under Windows 95 and Windows NT and the corporate standard LAN-based electronic mail system had problems in these environments, we selected
Microsoft Exchange Server. It provided us with a standard interface to expand onto the Internet when the time came and also met all of our needs in the short term. The Exchange client was frequently used by developers who had accounts with their own
Internet service providers.
The next requirement focused around group scheduling. There is no real intranet tool for group scheduling, so we used the LAN-based product Schedule Plus. It interfaces to Microsoft Exchange well for transmitting meeting requests, and it was good enough
for our relatively simple needs.
The next requirement was a more interesting one to satisfy. We needed a place to store information (specifications, project schedules, and so forth) where everyone could access it. This could have been done with a simple shared folder or some public
folders in Exchanger Server. The solution that we chose was to implement an Internet Information Server. The reasons that we chose this solution included the following:
The next task at hand was to provide a source code version control system. Again, there are no Internet standard protocols related to software version control, so we picked a traditional LAN-based product. This is another example where you will not find
intranet products to meet all your needs. The network environment that you construct will most likely be a mixture of LAN technologies and technologies that have their origin on the Internet.
The final requirement is that we needed a place where programmers could upload and download files to and from the server for others to access. Examples of this would be new software modules or executables for testing. Figure 6.3 shows this sample
intranet. We could have set up an FTP server area for them to work with. We could have made a series of folders under the main FTP server root directory for the various types of files that needed to be stored. Although this would have worked well, we chose
instead to use the standard Windows networking utilities to share folders.
FIGURE 6.3. Sample intranet implementation.
This may seem like heresy in a chapter that is devoted to intranets. Am I truly saying that FTP has no place in the world and that only Windows network shared directories are acceptable? Not at all. I am saying that for this particular installation, the
shared folder concept made the most sense. We came to this conclusion based on the following reasons:
This little example of an intranet installation should give you some food for thought. As you can see, even people who write books about BackOffice and sing the praises of intranets occasionally fall back and use conventional LAN tools when it makes
sense to do so. The key is to take just a few moments to write down your user’s needs and match them against the alternative products.
This section provides you with a basic mapping between the services that you might want to implement on your intranet and the products in the BackOffice family. You can find each of these products discussed in more detail in upcoming sections, but this
section can be your cross-reference of function versus product. These are the most common functions used on an intranet/LAN:
The electronic mail function is handled by Exchange Server in the BackOffice family. This product supports the standard Internet mail protocols and also a few of the Microsoft formats. There are, of course, a number of third-party products from Lotus
and smaller companies that perform the same function but are not as integrated into the BackOffice environment as Exchange Server. You also have the choice of installing the older Microsoft Mail product. This lacks the scalability of Exchange Server and
may not be supported in the distant future. One note, Exchange Server will force you to enter into a domain configuration as opposed to a workgroup.
When it comes to storing shared information you have basically four options. First, you can use shared folders on your server and tell people to browse these folders using File Manager, Network Neighborhood, or Explorer. This will work, but it is more
of a challenge to figure out what the person who wrote the file would call it. The second option is to use public folders within Exchange Server. You can make a series of topical folders and access them using your standard mail client. The third option is
to set up an FTP server and allow users to use FTP utilities to upload and download files. This is not as convenient as Windows-based shared folders, but it can be accessed by a wide variety of client workstations. The final option is to put up a Web
server. This may take a little bit more learning, but it is an interface that you can extend to meet a wide range of future needs.
For simple file storage, you have the same three options as for shared information. For this purpose, using shared folders is probably the simplest solution. An FTP server still has appeal if you wish to make your files available to people who use a
wide variety of operating systems. Finally, a Web site for this file storage is not that bad an option if the list of files does not change that often. It is still an easy paradigm to work with, but it can be a pain if you have to keep updating your Web
pages that link to the files.
Newsgroups is another feature that many intranet users desire. Right now, Exchange Server is being modified to accommodate downloading newsgroup information. It should be out by the end of 1996 or so. This will complete the list of major Internet
services that BackOffice can provide.
Finally, a traditional LAN application is that of the database management system. The usage is simple. You build a database and some access/reporting software and deliver it as a package to your users. The LAN mindset works and there is no need for any
Internet stuff. You can continue to do things the traditional way. However, Microsoft and other major vendors are working to enable you to access a database with a combination of a Web browser (for display of information) and a series of miniapplications
that are downloaded from the server (for business logic and processing). There are already some impressive sites that provide some relatively complex database access. This may become a trend in the future to help minimize the complexity of the distributed
computer resources on a network by downloading simpler applications only when they are needed.
You may notice that you are not logging into the host computer when you access a Web page. This is because you are actually accessing the system through a specially designed Web user account, which usually has full read permissions in the Web pages
directory. If you wish to control access to certain portions of the Web page, you are going to have to get a user ID and password combination from the user and have it validated before you continue with further processing.
Another feature that is often used is anonymous FTP. This data is made available to a default account that is set up for the FTP server. This makes it easy for you to provide a number of people with access to the data without granting explicit access
rights to them. If you use this feature and want to have some data restricted to only certain users, you need to set up subdirectories under that main directory that have access control permissions set accordingly (and use the NTFS file system).
Be aware of these common holes that were designed to promote better access to information at a slight cost in security. They can be dealt with rather easily if you know that they are there. You just need to decide whether you can live with the security
implications in return for the ease of access to that data. Your decision may have to be on a server-by-server, application-by-application basis.
This chapter provided an introduction to the subject of intranets. Most of the computer industry seems to be stressing intranets almost as heavily as they stress the Internet. This means that you will see a wealth of products in the near future that are based on this technology. This chapter presents some of the pros and cons associated with intranets to help you decide which environment best fits your situation.
