Special Edition Microsoft Exchange Server 5.5

Previous chapterNext chapterContents


- 10 -
NetWare Considerations/Migrating from GroupWise



There are many issues you must confront when installing Exchange in a NetWare environment, ranging from technical considerations to organizational concerns. You need to understand, support, and maintain both Microsoft's Domain Model and Novell's NetWare Directory Services, as well as determine what additional services, software, and migration tools are needed to enable both to coexist.

Understanding 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, LAN Manager 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 leveraged NetWare's popularity by designing NetWare Loadable Modules (NLMs) to run on top of NetWare servers. NetWare servers typically were purchased by individual departments in corporations, and eventually spread throughout the organization. Following this momentum, many corporations made heavy investments in NetWare because it provided the 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 Microsoft Windows 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. Because 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 connectivity to the server was established, Windows and applications were loaded from the server.

In the past three or four years, however, things have changed. 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 email and scheduling package to market a suite called PerfectOffice to compete with Microsoft Office. Novell and Microsoft were now both trying to capture the piece of the business they did not have previously.

Over time, however, the Novell application suite was not accepted by a large number of companies. Novell took a lot a criticism for losing focus on NetWare and for not providing adequate support for its core product. Novell has since sold WordPerfect and Quattro Pro, and is currently out of the applications business. During the time that Novell tested the application marketplace, they were also having problems with their first release of NetWare Directory Services (NDS) NetWare 4.0. This, and the fact that NLMs were very difficult to develop, encouraged people to start testing new networking and application platforms, such as Windows NT Server. As much as NetWare was initially brought into individual departments to provide file and print services, NT servers were brought into departments to run department-specific applications. Microsoft Windows NT began to gain market acceptance, and has been gaining market share ever since.

Because of its stability, integration with Microsoft Office, open programming interfaces, and support of Internet protocols, Exchange will be successful in any environment, including those with Novell servers. The Exchange client components integrate very closely with all the Microsoft Office 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 in 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 about your server when implementing Exchange. These include the following:

Choosing a Network Protocol

The NT server that Exchange runs on can communicate over several protocols. The two most widely used protocols in the NetWare environment are IPX/SPX and TCP/IP. NT supports both of these protocols out of the box, enabling your NetWare clients to communicate seamlessly over the 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. This is because clients will be looking for Exchange servers on the network based on the servers' NetBIOS names. NetBIOS is not required on the workstations, but can be used if desired.

Migrating User Accounts to NT Servers

Because most packages require you to create a separate account for email, 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. Much of this will have to change when you install Exchange. Although your clients will need minimal or no special configuration, the changes required at the server 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 Windows NT domain security. This means that an Windows NT domain account must be created for every NetWare user who will be using Exchange. This link to Windows NT security will provide the user with powerful permissions features, including the ability to delegate certain responsibilities to other users. If you wanted your secretary to be able to access your appointment book, for example, you could allow that. You may assign or deny very detailed levels of permissions to other users.

Given the preceding, the biggest job you will have is importing all the current users and data from your current email 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.

In most email environments, however, the user's full name is listed in the email directory. If you import a bindery from a NetWare server, and 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 if you want to make them easy to find in the directory.

You can overcome this by using one of the mail migration utilities that ships with Exchange, or a third-party tool. If you have Microsoft Mail post offices spread throughout your NetWare network, for example, you can run the Migration Utility and select Microsoft 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 Windows NT user accounts for you, thus making the transition seamless.

Moving Existing Data

When changing from a NetWare-based e-mail system to Exchange, moving data is made easier by Microsoft and third-party data migration utilities. Utilities provided by Microsoft include Gateway Services for NetWare and the Migration Wizard. Gateway Services for NetWare is a service included with NT Server. It is installed from the Services tab on the Network icon in the Control Panel. The Exchange Migration Wizard is included with Exchange and may be installed during setup.

With Gateway Service for NetWare, you can access file and print resources on NetWare servers from your computer. You can access resources on NetWare 4.x servers that use NDS and on NetWare servers that use bindery-style security. NT's Gateway Services for NetWare enables the NT server running the Gateway service to mount NetWare volumes. This feature enables users on Microsoft NT networks to access volumes on a Novell server. The administrator of the NT server logs in to 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 feature 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 email package such as MS Mail.

NetWare servers use the Service Advertising Protocol (SAP) to announce their available resources. To enable NT Servers to communicate with NetWare Servers, Gateway Services also uses the SAP protocol. When you install Gateway Services, you must also install the SAP Agent that comes with NT Server. The SAP Agent can be installed from the Services tab on the Network icon in the Control Panel.

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. NT Server provides this functionality 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.

NT Server Expertise

As discussed in previous chapters, Exchange integrates tightly with Microsoft Windows NT Server. Because Windows NT includes an easy-to-use graphical interface that is identical to the interface on their desktop PCs, many corporate managers assume that NT Server requires as little planning to install and implement as their desktop operating system. Do not fall into this trap. A reliable, robust email system requires a sound foundation. Like NetWare, NT Server is a fairly complex product--those installing it should understand the implications of their design decisions.

An exhaustive explanation of NetWare administrators who need to learn more about NT Server will benefit from attending training courses provided by Microsoft Authorized Technical Education Centers (ATEC). For current information on Microsoft Education, you may reference the Microsoft Training and Certification Web site at www.microsoft.com/train_cert/.

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 the necessary 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 Remote Procedure Calls (RPCs). These RPCs travel between the Exchange Server and the NetWare client software via the SPX protocol. If a NetWare client is having trouble connecting to an Exchange Server, one item to check is the IPXODI entry in the client's Startnet.bat file. Make sure the IPXODI entry does not include the /A switch, which disables SPX on that client. The SPX protocol is sometimes disabled because it uses additional memory on the client.

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. 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. In the current cc:Mail and Microsoft Mail implementations, for example, the user must provide a drive letter and path to the post office. That means they must be logged in to 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 email system. Users have different passwords for login and email. The two systems are completely separate, with the exception of MHS-based systems such as 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 email systems. Keeping database pointers in line, getting clean backups, and shutting down the system to make changes are all problems 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 enables the NT server housing Exchange to access NetWare volumes.

Using the Exchange Migration Tool

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 also 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.

Coexistence of NetWare and Windows NT Server

Rather than migrating your existing NetWare server-based e-mail system to Exchange, you might consider coexistence. 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. ABC uses MS Mail as their 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 email messages going through two gateways: one for students and one for everyone else.

Meanwhile, the time and resources required to perform database maintenance were becoming unacceptable. If the utilities weren't run every night, the database would get corrupted, causing the entire system to be shut down during peak hours. Additionally, data was being lost in the process. Also, the amount of storage needed to run the utilities was getting excessive, requiring that the entire database be moved to a separate server for the utilities to be effective. Needless to say, the system was breaking down.

This scenario led ABC to explore the possibility of migrating the students to Exchange because of its client/server architecture. Rather than 3,000 students sharing one post office file on one Novell server, the company could move to the client/server model. They wanted to preserve their investment in NetWare, but at the same time wanted to move to Exchange for messaging.

To meet both objectives, ABC 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.

ABC 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 training on Windows NT fundamentals.

Because 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 by using a batch file that ran upon login to the Novell server.

The users were then provided with an online tutorial using the company's intranet. These pages helped ease the transition from MS Mail to Exchange for the users and reduced the number of calls to ABC's help desk.

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. They also 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. ABC edited this script to create the proper Exchange account information.

This implementation of coexisting systems can work in many environments. In addition, once the word spreads among the user community about how good the email 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.

Migrating from NetWare to Windows NT Server

The introduction of Exchange by Microsoft may prompt the discussion of a complete migration from NetWare to Windows NT Server. This is because for so many organizations, email and group collaboration are the main reasons for having a network in the first place.

Combined with the introduction of Exchange are 32-Bit desktops, Windows 95, and 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, such as Software Spectrum http://www.softwarespectrum.com or Microsoft Consulting Services http://www.microsoft.com/Exchange, for more information about moving your organization off NetWare and onto Windows NT Server.

Understanding 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. Not putting this technology into place due to the lack of expertise in the organization may be shortsighted.

You can turn to the following channels to get Exchange rolled out in your environment:

Power Users

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 management to support an Exchange rollout.

Newsgroups and Web Pages

There are several newsgroups on the Internet that are related to Windows NT and groupware. 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 sites solely dedicated to NT technologies that will definitely include Exchange. These sites include the following:

Microsoft Solution Providers

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 with your Microsoft Windows NT and Exchange projects, as they have the expertise and can assist in one or all phases of the project. They can be used in any phase of your project, starting with development and deployment to the support and maintenance of your Exchange environment. Working with a Solution Provider delivers many benefits, including firsthand information, and most importantly, knowledge transfer. Most are also 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. You can find a list of Microsoft Solution Providers on Microsoft's Web site at http://www.microsoft.com.

Microsoft Consulting Services

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 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 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 5.5, 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. The beta program for Exchange 5.5 was offered to a select group of clients. Others keep up-to-date by accessing Microsoft's Exchange Web site. Microsoft's Web sites offer the public the opportunity to participate in many of Microsoft's product evaluations, and users can acquire product support and access to online knowledge bases.

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, MS Mail, and Microsoft applications such as Excel, Word, and PowerPoint.

These organizations have made 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.

Breaking the NetWare Culture

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, and their 32-bit Intranet Client for Windows 95 and Windows NT 3.51 and 4.0 workstations. 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. 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.

Connectivity isn't the only issue, however. 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 enable Windows NT servers to be managed as NDS objects.

In addition, users must be migrated to the Exchange server; and more importantly, staff has to be trained on NT Server because Exchange is so closely tied to the Windows NT 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, because of the IBM acquisition of Lotus, Notes is being pushed very aggressively, as Lotus Notes offers Notes mail and Groupware solutions. A 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 are 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 Windows NT Workstation 4.0. 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.

Committing to an All-Microsoft Strategy

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; however, 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.

Unlike the old IBM, however, Microsoft has built an open architecture using the MAPI and COM/DCOM 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 previously outlined 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.

Migrating from Novell GroupWise

Migrating users from Novell GroupWise to Microsoft Exchange requires detailed planning, and you will need to understand Windows NT and Microsoft Exchange architectures. Microsoft Exchange Server has many migration tools to be used with Novell GroupWise.

Planning the Migration

As you plan your migration, you will need to consider the following:

Tables 10.1 and 10.2 show which mappings are supported during the coexistence of both Novell GroupWise and Microsoft Exchange in an environment, and details folder mappings of migrated information.

Table 10.1  Content Mapping

GroupWise Microsoft Exchange
MessagesRead Note
Note Request Read Note (Textized)
Appointment Request Read Note (Textized)
Task Request Read Note (Textized)
Phone Request Read Note (Textized)
Routing Slip Read Note (Textized)
Calendar Data Schedule+

Table 10.2   Folder Mapping

GroupWise Microsoft Exchange
Inbox Inbox
Inbox\UserName Inbox
Inbox\Username\subfolder Inbox\subfolder
OutBox Sent Items
OutBox\Username Sent Items
OutBox\Username\subfolder SentItems\subfolders
Trash (not migrated)
Trash\Username (not migrated)
Personal Folders Personal Folders
Personal Folders\subfolder Personal Folders\subfolder
Week View Schedule+ Calendar

Migration strategies, coexistence and full migration plans are detailed in both Chapter 8, "Migrating from Microsoft Mail Systems" and Chapter 9, "Migrating from Lotus cc:Mail." These chapters detail migration strategies from Microsoft MS Mail and Lotus cc:Mail to Microsoft Exchange, and they can assist you with the planning, development, and deployment from Novell GroupWise to Windows NT and Microsoft Exchange.

Using the Migration Wizard

After your Microsoft Exchange Server and Novell GroupWise systems are connected, it is easy to enable them to coexist or migrate from Novell GroupWise to Microsoft Exchange. Microsoft Exchange Server offers a Migration Wizard to assist you with migrating. The Migration wizard assists you with the creation of new Windows NT accounts, and you can select how you want the Windows NT accounts for your migrated users created (accounts can be created and given a random password). An Exchange mailbox is not accessible until a Windows NT account is associated with it.

The Novell GroupWise migration tool is tightly integrated, and enables you to extract data from Novell GroupWise systems, create mailboxes, and import data. The Migration Wizard is the interface to the GroupWise Source Extractor, which takes information from a foreign mail system and puts it into a neutral format, which can then be imported into Microsoft Exchange (see Figure 10.1). The Novell GroupWise Source Extractor will migrate user accounts, Mail and Phone messages, Appointments, Notes and Tasks. When migrating users from Novell GroupWise to Microsoft Exchange, you have the option to migrate all Appointments, Notes and Tasks, or to select a start and ending date. There are a few prerequisites to running the Novell GroupWise Source Extractor: All users that are to be migrated must grant migration ID access to Mail and Phone messages, Appointments, Notes and Tasks before their data is exported.

FIG. 10.1 Novell's GroupWise 4.1 Source Extractor converts data to a neutral format that Exchange can see.


Previous chapterNext chapterContents