Copyright
©1996, Que Corporation. All rights reserved. No part of this book
may be used or reproduced in any form or by any means, or stored in a database
or retrieval system without prior written permission of the publisher except
in the case of brief quotations embodied in critical articles and reviews.
Making copies of any part of this book for any purpose other than your
own personal use is a violation of United States copyright laws. For information,
address Que Corporation, 201 West 103rd Street, Indianapolis,
IN 46290 or at support@mcp .com.
Notice: This material is excerpted from Special Edition Using Microsoft Exchange Server, ISBN: 0-7897-0687-3. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
There are many issues you must confront when installing Exchange in a Netware environment. They range in nature from technical considerations to organizational concerns.
In this chapter, you learn about:
The History of Microsoft and Novell
Many years before Microsoft created Windows NT, their network operating system platform was a product called Microsoft LAN Manager. Without getting into the details, it didn't sell very well, and Novell captured the networking market with its Netware product line.
As Novell set up shop on corporate Local Area Network (LAN) servers, Microsoft chose to go after the desktop operating system market. Microsoft introduced its Windows 3.0 product. It ran on top of DOS, but was a revolutionary advance in design and function from Microsoft's Windows 286 and Windows 386 environments. Its application software for Windows consisted of Word, Excel, PowerPoint, Mail, Schedule+, and Project. Microsoft also developed Dynamic Data Exchange (DDE) and Object Linking and Embedding (OLE) technology that tied its applications to one another and provided a robust desktop platform.
The two worlds remained separate. Developers of networking technologies continued to leverage Netware's popularity by designing Netware Loadable Modules (NLMs) to run on top of the Netware servers. Many corporations continued to make heavy investments in Netware because it provided the best, most extensible, cost effective networking solution on the market.
As a result of these two companies' abilities in different market segments, there were many Netware networks running with Windows Operating System and Windows applications on the desktop. In fact, several organizations even executed Windows from the Netware server.This enabled administrators to manage users' Windows profiles and Windows application software configurations from any workstation because all initialization files were kept on the server. Since Windows ran on top of DOS, all of the workstation network card and protocol drivers could be loaded in DOS, and a drive letter could be assigned to the Netware volume. Once the connectivity to the server was established, Windows and applications were loaded from the server.
In the past year or two, however, things have changed a bit. Microsoft introduced Windows NT as a network server solution, and Novell acquired WordPerfect and Borland's Quattro Pro spreadsheet. Novell then bundled these applications with its Groupwise e-mail and scheduling package to market a suite called PerfectOffice to compete with Microsoft Office. This was a 180 degree turn from the previous situation. Novell and Microsoft were trying to capture the piece of the business they did not have previously. However, the Novell applications were not accepted by a large number of companies, with the exception of WordPerfect.Novell took a lot a criticism for losing focus on Netware and for not providing adequate support for its core product. This encouraged people to start testing new networking platforms like Windows NT Server.
After those very turbulent years, however, Novell is out of the applications business; and Microsoft is moving further ahead with NT and the applications software that made it such a dominant player in the market.
The dominance of Microsoft Office applications and technologies like OLE are the reasons why Exchange will be successful in any environment, including those with Novell servers. The Exchange client components tie very closely with all the Microsoft products. Third-party companies write applications to the standard Application Programming Interfaces (APIs) that Microsoft incorporates into its products. The underlying networking technology and protocols should not sway you from implementing Exchange. Exchange's client-server model, integration with other Microsoft applications already use, and its open programming architecture will provide a solid foundation for your organization to build a global messaging architecture.
Exchange Installation Server Considerations
There are several things to consider on the server side when implementing Exchange. These consist of:
The NT server that Exchange runs on can communicate over several protocols. The two real choices in the Netware environment are IPX and TCP/IP. NT supports both protocols out of the box, enabling your Netware clients to communicate seamlessly over the already existing network without modifying the client workstation protocols or adding new protocols to your routers.
This leads to an important point. You must have NetBIOS support enabled on all the NT Servers that will be acting as Exchange servers. The reason for this is that the clients will be looking for Exchange servers across the network based on their NetBIOS names. NetBIOS is not required on the workstations, but can be used if desired.
Since most packages require that you create a separate account for mail, you already have systems in place for generating new accounts. In addition, users are already familiar with the interface; and you, the administrator, are already familiar with all the back-end utilities that go along with running the mail system. You already have backup procedures in place as well. All of this will have to change when you install Exchange. Although your clients will need minimal or no special configuration, the server side of things will be a bit different.
There are a few things you will have to keep in mind. One is that Exchange security is tied to NT domain security. This means that an NT domain login must be created for every account. This will provide the user with powerful permissions features that allow users to delegate certain responsibilities to other users. For example, if you wanted your secretary to be able to access your appointment book, you could do it. You are able to get very granular as to what permissions are assigned to certain users.
Given the above, the biggest job you will have is importing all the current users and data from your current e-mail system.
Although Microsoft provides a bindery migration utility, it will import only the Netware user names and group memberships. The problem with that is in most Netware environments, user names are based on a first initial, last name or first name, underscore, last name standard because spaces are not allowed in Netware user names.
However, in most e-mail environments, the user's full name is listed in the e-mail directory. If you import a bindery from a Netware server, then run the NT User List to Exchange migration utility you will wind up with a list of first initial, last name entries, rather than full names. This is unsatisfactory because you will have to go back and re-key all the user names.
You can overcome this shortcoming, however, by using one of the mail migration utilities that ship with Exchange or a third-party tool. For example, if you have Microsoft Mail post offices spread throughout your Netware network, you can run the Migration Utility and select MS-Mail, and that will create the Exchange users with full names while migrating data. As the Exchange users are created, you can have the utility create the NT user accounts for you, thus making the transition seamless.
When changing from a Netware-based e-mail system to Exchange, moving data is made easier by the Microsoft and third-party data migration utilities. These utilities are:
This standard NT feature allows NT servers to mount Netware volumes. The purpose of this feature is to allow users on Microsoft NT networks to access volumes on a Novell server. The administrator of the NT server logs into the Novell server and mounts the disk as a logical drive. The NT server can then share this device with any NT Server user. The same thing applies to printers on the network. You can associate a Netware print queue with an NT print queue and provide seamless access to authorized users on the NT Server. While this may seem unconventional in a predominantly Netware environment, it does provide some very interesting functionality. This tool can prove very useful when using the Migration Wizard to move users from a Novell server-based e-mail package like MS-Mail.
If the post office exists on Novell file server NOVELL001, on volume SYS1:, you can mount it on the NT server as drive D:, and just perform your import seamlessly. This functionality is provided by NT Server out of the box. Think of the alternative. You would have to copy all the associated post office files to a workstation and then copy them to an NT server.
Exchange Installation Client Considerations
There are many different ways a client workstation can be configured in a Netware network. For workstations using DOS/Windows 3.1 or DOS/Windows for Workgroups, 16-bit real mode drivers are used to access the Exchange server over IPX or TCP/IP.
In an IPX configuration, the IPXODI driver provides all the needed connectivity to the Exchange server. Through the use of the NWLink protocol on the Exchange server, the IPX client can seek out the Exchange server on the network. Once a connection to the server is established by the Exchange client software, all communication is handled through RPC.
When installing the Exchange client software on a DOS, Windows 3.1, or Windows for Workgroups 3.11 machine, the installation program looks for a file called NETAPI.DLL. It then copies the appropriate RPC communication DLL based on the version of that file.
If you have TCP/IP running across your network already, and all the software is already installed on the workstation, you can have clients use TCP/IP to connect to the server. As long as the stack you use is Winsock compliant, the connection should be seamless.
For Windows 95 clients, using Microsoft's 32-bit IPX and TCP/IP drivers for your network card will provide robust connectivity. If you have these drivers already in place to access the Netware servers on your network, this same set of drivers will be used by the client to access the Exchange servers. One note is to make sure that if you are using the IPX protocol to communicate with Exchange, the Windows NT server will need to have the IPX protocol installed.
The client-server architecture of Exchange eliminates the need to actually mount any volumes of the server. The client communicates with the server via Remote Procedure Calls (RPCs) to provide seamless communication. For example, in the current cc:Mail and Microsoft Mail implementations, the user must provide a drive letter and path to the post office. That means they must be logged into the server and have the proper search paths and drive mappings established to communicate with the post office. With Exchange, all you have to do is configure the client to look for a certain server on the network. RPCs take care of the rest of the communications once the Exchange server is found on the network.
Exchange Migration Considerations
There are many sites that use Netware servers to house their shared file e-mail system. Users have different passwords for login and e-mail. The two systems are completely separate, with the exception of MHS-based systems like Novell's Groupwise, which ties into the bindery or NDS. For these organizations, there are real benefits to installing Exchange.
The movement away from the shared file system to client-server is a real boon to the administrators of those e-mail systems. Keeping database pointers in line, getting clean backups, and shutting down the system to make changes are all things these administrators have come to know all too well.
There are several tools at your disposal to bring Netware users into the Exchange environment. You can use the Migration Tool that ships with Exchange or you can use the Bindery Import Tool that comes with Windows NT Server. The two solutions yield different results that will be explained in the sections that follow. In addition, Gateway Services for Netware allows the NT server housing Exchange to access Netware volumes.
When you use this tool to give Netware users access to Exchange resources, that is all the Netware users will have. They are not given logons to the NT domain.
Think of your current LAN-based e-mail system, be it cc:Mail, MS-Mail, or POP. When you launch the client application on your PC or Macintosh, you are prompted for a login name and password, and the back end mail engine authenticates you. This same thing happens when you use the Migration Tool for Exchange.
Exchange can be thought of as an upgrade to your current mail system that will provide so much extra functionality. Microsoft has provided many tools that make Exchange an easy platform to implement regardless of your current server environment.
Although this system lacks the single logon benefit that comes along with running NT Server, it is still very manageable and very robust.
Rather than migrating your existing Netware server-based e-mail system to Exchange, you might consider co-existence. Through Exchange's wide variety of bundled connectors, you can make the most of new technology while keeping your current system up and running. Consider the following real-world example.
ABC's Information Services Department uses Netware servers on the backbone of the campus-wide network. The system has grown to over 5,000 users, all with Netware 3.12 accounts. They use MS-Mail as the messaging platform.
Recently, the MS-Mail infrastructure has been showing signs of weakness because of the load being put on all the servers. The message databases have grown to over 500 megabytes, with thousands of Internet e-mail messages going through two gateways, one for students, one for everyone else.
At the same time, the need to perform database maintenance was becoming prohibitive. If the utilities weren't run every night, the database would get corrupted, causing the entire system to be shut down during peak hours. In addition, data was being lost in the process. Also, the amount of storage needed to run the utilities was getting excessive, causing the need for the entire database to be moved to a separate server for the utilities to be effective. Needless to say, the system was breaking down.
This scenario lead ABC to explore the possibility of migrating the students over to Exchange because of its client-server platform. Rather than 3,000 students sharing one post office file on one Novell server, the company could move to the client-server model. However, they wanted to preserve their investment in Netware, but at the same time wanted to move to Exchange for messaging.
They set up an Exchange server for students to access mail, while still using the Netware server to load Windows 3.1 and house the Exchange client software. They used the Exchange Migration Tool to import the user data and accounts from the existing MS-Mail system so no data loss occurred.
They then called a Microsoft Solution Provider who installed the MS-Mail connector and set up the proper Directory Synchronization in the connector properties so that any new accounts created on the MS-Mail side would be reflected in the Exchange Global Address Book for the students. The Solution Provider gave ABC information on how to get hands-on Exchange training along with some basic Windows NT fundamentals.
Since IPX was the standard protocol loaded on the workstations, there were no workstation issues that needed to be addressed. The Exchange client software was loaded onto the Novell server, and a central program group was created and added to each user's PROGMAN.INI file using a batch file that ran upon login to the Novell server.
The users were then provided with an on-line tutorial using the company's internal World Wide Web pages. These pages helped ease the transition from MS-Mail to Exchange for the users.
By implementing this solution, the company minimized the expertise needed on the Windows NT side of the house by using the migration tools that came with Exchange. In addition, they continued to use their Novell server as a distribution medium as well as a file repository. The login script capabilities of Netware were utilized in rolling out the client software to the workstations.
The one issue ABC must deal with is creating new users on the Novell server. They used to have the MS-Mail user accounts automatically generated through the same script they used to create Netware accounts. They edited this script to create the proper Exchange account information.
Can this be done, and how so? This implementation of co-existing systems can work in many environments. In addition, once the word spreads among the user community about how good the e-mail system can be, you can leverage this demand when proposing a full migration as well as when deliberating the use of Exchange's more advanced groupware features.
The introduction of Exchange by Microsoft may prompt the discussion of a complete migration from Netware to Windows NT Server. The reason for this is that for so many organizations, e-mail and group collaboration are the main reasons for having a network in the first place.
Combined with the introduction of Exchange are Windows 95 desktops and the forthcoming release of Windows NT Workstation 4.0. As these 32-bit platforms roll out onto the desktop, migrating file and print services to Windows NT Server may be a more strategic decision. You may already have Microsoft application software. When you combine that with Exchange, and then Windows NT Server and BackOffice, you have a completely integrated Microsoft networking solution.
You should consult a Microsoft Solution Provider for more information about moving your organization off Netware and onto Windows NT Server.
See the upcoming section on Microsoft Solution Providers.
The Role of Systems Integrators and Consultants
Many environments consist of nothing but Netware for file and print services. The organizations that operate in that environment choose Netware because it is very popular and there is a lot of third-party support for the platform. In addition, choosing one platform leverages all the staff training across the organization.
Trying to roll out Windows NT servers to implement Exchange might seem like an impossibility in these environments; however, there are several benefits to using Exchange that have been described throughout this book, and not putting this technology into place due to the lack of expertise in the organization may be short sighted.
You can turn to the following channels to get Exchange rolled out in your environment:
These are the people in the organization who experiment with different technologies on their own time. You know who they are. These people are the ones who can train the other system administrators on NT concepts and work with the management to support an Exchange roll out.
There are several newsgroups on the Internet that are related to Windows NT and groupware. These are under the hierarchy of comp.os.ms-windows.nt.*. They include such topics as administration, networking, hardware, services, compatibility, and advocacy. These groups are a great resource for getting in touch with people who run NT-based networks.
In addition, there are Web pages solely dedicated to NT technologies that will definitely include Exchange. These sites include:
There are many consultant agencies and systems integrators that are certified by Microsoft as Solution Providers. Just as the Novell environment has the Certified Netware Engineer (CNE) program, Solution Providers must pass tests and spend a certain number of hours using the platform to be certified by Microsoft.
You can count on these professionals to assist you in planning and implementing Exchange. Most are very familiar with Netware servers and clients because many Windows NT shops migrated from Netware with the help of Microsoft Solution Providers. Contact Microsoft to get a list of Solution Providers in your area.
For those organizations that will settle for nothing but the real article, Microsoft has a division to help you implement Microsoft technology solutions. These professionals provide the soup-to- nuts support with all the backing of Microsoft.
This group is a step up from the Solution Providers because they have access to all the resources of Microsoft including all the constant, up to date training, and experience with the product. This is especially important in the case of Exchange. Many companies have been eagerly awaiting the delivery of Exchange, and Microsoft Consulting Services has the benefit of having gone through the beta testing of the product and all the knowledge gained from that testing.
Organizational Considerations
In addition to the networking and technical considerations involved when installing Exchange in a Netware environment, some organizations will have to undergo serious change in their IS departments, especially in those shops running Netware servers and MS-Mail and Microsoft applications like Excel, Word, and PowerPoint.
These organizations have made such a large investment in Microsoft technologies, but the network server platform has always been Netware. There may be great opposition in the organization to move to Exchange because it means that Windows NT server must be rolled out into the entire enterprise just to upgrade MS-Mail. Some managers will be harboring resentment toward Microsoft for painting them into a corner.
Novell, now rededicated and refocused on expanding its core technology competencies in networking, is strongly marketing and supporting its Netware 4.1 platform with Netware Directory Services (NDS), a global directory service. This rededication has reassured many companies that their Netware investments are indeed safe.
Many Netware shops are starting to outgrow their LAN-based e-mail packages and are looking for more robust client-server solutions for e-mail and groupware. Exchange will function very well in Windows NT and Netware shops alike. Yes, the Exchange server must be an NT server; but as long as the connectivity is provided from the client to the server, there is no problem.
However, connectivity isn't the only problem. In many Netware-dominated shops, Windows NT is not a welcome solution. Since it isn't a Netware server, it takes no advantage of NDS trees already in place, although Microsoft is developing utilities that will allow Windows NT server to be managed as NDS objects.
In addition, users must be migrated to the Exchange server; and more important, staff has to be trained on NT Server because Exchange is so closely tied to the Microsoft operating system. This may be the biggest barrier to entry into Netware environments for Exchange. Many administrators might ask, "Why not use Groupwise for e-mail and groupware?"
Also, since the IBM acquisition of Lotus, Notes is being pushed very aggressively. Notes server can be run on a Novell server, thereby strengthening the resolve of some administrators to keep Windows NT out of their shops.
It is advisable to keep in mind that Exchange will be heavily tied into the operating systems you will run on the desktop, along with the applications being run on the desktop. In the future, the server platform used to file and print services will become less important. What will become increasingly important is the applications that can be run on top of the server operating system.
Exchange ties in very closely with the Windows 95 operating system, as well as the upcoming Windows NT Workstation 4.0 that is currently in beta as this book is being written. As your workstations change from DOS/Windows 3.1 to these newer 32-bit operating systems, Netware's dominance as the back end server will decline because these new Microsoft desktop operating systems make it very easy to participate in NT domains and use the resources within them.
Many managers might be wary of committing to an all-Microsoft strategy. Not wanting to put all your eggs in one basket is a legitimate concern; however, you may want to consider the following points:
These points address many of the concerns of information technology managers. These concerns stem from the experience of IBM dominance of the mainframe market in the early days of mainframe computing. The solutions were very proprietary, very expensive, and hard to learn. The one thing to remember was that they worked. As long as you stuck with an all-IBM solution, you felt comfortable because everything worked together, and IBM engineers were familiar with the equipment.
Microsoft's product line of today has some of the same characteristics. It is well integrated, and there are many well-trained engineers who know the software.
However, unlike the old IBM, Microsoft has built an open architecture using the MAPI and OLE standards combined with the Win32 SDK to enable third-party vendors to extend the capabilities of the core products.
In addition, there are several channels of support which were outlined above that should allay the concerns of managers. You can feel secure that although you're committing to Microsoft products, you are not dependent on Microsoft for support and extensibility.
From Here...
As you can see, there are many issues you'll have to consider when installing Exchange in a Netware environment. Some obstacles you'll face are technical, some are organizational; but you'll find the robustness of Exchange will be a vast improvement over your existing file-sharing e-mail system.
The areas of concern are as follows:
With the help of trained professionals, you will be able to work out all these issues and come up with an installation that makes the most sense for your organization. This chapter was intended to provide a starting point for any organization using Netware, to point out the relevant questions.
The following chapters contain more information on topics talked about in this chapter:
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation