|
|
ABOUT
SOFTWARE
DOCUMENTATION
KNOWLEDGE
RESOURCES
|
|
Migration Issues Guide
Introduction
Address Fidelity
Address fidelity refers to the ability to successfully route messages between systems without generating a Non-Delivery Receipt (NDR). Depending on the complexity of the messaging systems and coexistence strategies chosen, this can be a difficult task and clients need to decide what level of address fidelity is required during and after the migration.
The address fidelity problem is due to how messaging systems route messages. Microsoft Mail, for instance, uses a 10/10/10 identifier to route messages and GroupWise uses a similar MHS-style addressing scheme. Both styles of addresses are made up of Network/Post Office/User ID. When a user mails a message, that message is “stamped” with the 10/10/10 address of the user sending the message. If the sender is moved to Exchange and the recipient subsequently replies to the message, the message may be undeliverable unless specific steps have been taken to preserve address fidelity.
Mail-Enabled Applications
Mail-enabled applications are applications that have some kind of tie-in to email. This ranges from applications that have a button to allow the emailing of a document from within the application to applications that tightly integrate with email in the form of storing data within the email system or the use of custom email forms. Luckily, the de facto standard for email client applications is MAPI and the de facto standard for email transport is SMTP. Thus many of the mail-enabled application issues from the past no longer present a serious hurdle to overcome during migration. However, organizations must still perform due diligence in discovering mail-enabled applications within the enterprise and ensuring that these applications will still work with the new email system.
- Discovery – Discovery involves talking with business units and individuals to determine if they utilize applications that are mail-enabled.
- Implementation – If mail-enabled applications are MAPI or SMTP-based in their operation then there should be no specific implementation issues since Outlook and Exchange use MAPI and SMTP natively. Mail-enabled applications based upon alternative messaging standards such as VIM or X400 must be examined on a case-by-case basis to determine if the application is still required and exactly how it can be supported in the new environment.
Shared Calendars
In GroupWise, users can share calendars with one another. This generally occurs between an admin and their assistant. Outlook and Exchange also has this capability. The issues with shared calendars in terms of migration are primarily if and how these shared calendars will be migrated as well as how these shared calendars will be implemented within Outlook and Exchange.
- Discovery – Discovery only needs to occur if end users will not be configuring their own shared calendars.
- Implementation – Implementation can occur in one of two ways. One method is to have the end users configure this themselves. The shared calendar users would need instructions and/or training to perform these actions. This could be covered in email user training. Alternatively, a dedicated resource could configure these calendars and permissions.
Shared Folders
Shared folders primarily involve discovery and implementation. In GroupWise, users share personal folders with others. In Outlook and Exchange, this model is possible, but not recommended. Instead, it is recommended to use public folders for this purpose. To migrate these folders, some form of discovery needs to take place to identify these folders. Then, an evaluation will need to be made to determine whether the folder should become a public folder. Evaluation criteria includes relevance, current usage, etc.
- Discovery – Discovery essentially consists of communication to all mailboxes asking for the identification of whether they use shared folders, what those folders are, what they are used for and whether the user believes that they should be migrated to public folders. Also, depending on the implementation strategy, the permissions to those shared folders might also be a required part of discovery. See “Appendix D: Communication to Users About Shared Folders”
- Implementation – Implementation consists of creating the public folders and assigning permissions. There are several implementation issues that must be considered. First, will existing data be copied to public folders? If so, who will copy data to the public folder, end users or a dedicated resource? If the end user, then they will require instructions and/or training for performing this action. This could be covered in email user training. Alternatively, a dedicated resource could use the output of the discovery and evaluation to log into each user’s mailbox that had shared folders and move the data. Second, who will define permissions for these public folders. There are two approaches. The first approach is that a dedicated resource assigns a primary owner to each public folder. The primary owner would be the user with the shared folder in GroupWise. This user could then configure permissions for others. The public folder owners would need instructions and/or training to perform these actions (could be covered in email user training). Alternatively, a dedicated resource could configure these permissions.
Functional Recipients
Functional recipients, or Functional ID’s, are defined as those recipients created purely for business process reasons. Functional recipients represent a business function, role or similar corporate designation.
Functional ID's represent a departure from the standard configuration of a single mailbox being associated with a single NT account. Many different people need to access the information associated with a functional ID. In addition, these users need to access the information in the functional ID from many different workstations. The following are possible methods for meeting the need of functional ID’s:
- Functional ID’s as Distribution Lists
- Functional ID’s as Generic AD Accounts and Mailboxes
- Functional ID’s as Public Folders
All of these solutions present an increase to the administration of the system and will have some effect on the Exchange and NT system resources.
The pro’s and cons of each of these potential solutions are analyzed below.
Functional ID’s as Distribution Lists
Under this scenario, a distribution list is configured for each functional ID. Users who require access to the information going to the functional ID become members in the distribution list. Messages sent to the functional ID are sent to all participants in the distribution list.
Pros
- Most administrative authority can be given to the users.
- All users access information from their own mailbox. Therefore, any user can be logged on to their account and see the messages.
Cons
- Multiple “copies” of messages.
- Initial Administrative cost of creating and assigning NT account permissions to the mailbox.
- Administrative cost associated with maintaining certain permissions.
- Added support cost due to increased complexity in work environment.
- Departure from current business practice.
- Increase in the size of the Exchange directory. The Exchange directory is approximately 65 Mb, which is about 4K per object.
- Increase in the storage capacity of the Exchange server information store.
Functional ID’s as Generic AD Accounts and Mailboxes
Under this scenario, an AD account and an Exchange mailbox are configured for each functional ID. Users of the functional ID log out from the network and log back onto the network as the functional ID or open the additional mailbox from within Outlook.
Pros
- Uses a single migration strategy for all mailboxes
- Single “copy” of messages.
- Some administrative authority can be given to the users.
- Administrative cost of assigning permissions is low.
- Fits current business model.
Cons
- User must log on as the AD account or access separate mailbox
- Initial Administrative cost of creation and assigning AD accounts permissions to the mailbox.
- Network security risks in having a generic AD account.
- Exchange security risks in having a generic Exchange mailbox.
- Administrative cost associated with assigning certain permissions.
- Users external to the location must use the WAN to access information.
- Increase in the size of the Exchange directory. The Exchange directory is approximately 65 Mb, which is about 4K per object.
- Increase in the storage capacity of the Exchange server information store.
- Increase in size of NT directory.
Functional ID’s as Public Folder
Under this scenario, a public folder is configured for each functional ID. Users who require access to the information going to the functional ID open the public folder from their standard Exchange client.
Pros
- Single “copy” of messages.
- Most administrative authority can be given to the users.
- Administrative cost of assigning permissions is low.
- Ability to replicate information between servers.
- User can access functional mailbox no matter who is logged on to the workstation.
- Continued management costs on Exchange side are low.
Cons
- Added migration complexity.
- Generally a departure from current business practice.
- Administrative cost associated with assigning certain permissions.
- User training required teaching how to work with public folders.
- Added support cost due to increased complexity in work environment.
- Increase in the size of the Exchange directory. The Exchange directory is approximately 65 Mb, which is about 4K per object.
- Increase in the storage capacity of the Exchange server public information store.
Recommendations
For most organizations, public folders are the recommended approach to functional recipients. This eliminates security concerns and provides a clear distinction between functional recipients and mailboxes. It is further recommended that role-based security groups be created for each public folder for assigning permissions.
Distribution Lists
Distribution lists are fairly straight-forward to migrate since they work essentially the same in both GroupWise and Exchange.
- Discovery – Discovery is fairly easy as all distribution lists and their members can be exported from NDS.
- Evaluation – Each distribution list should be evaluated according to a set of criteria to determine whether it is still valid and needed. An email may be composed and sent to all mailboxes asking for users to identify distribution lists that they use.
- Implementation – Unless there are a huge number of distribution lists, it makes the most sense to simply make this a manual process of creating the group, mail enabling it and adding members to it. This will be good practice for Exchange administrators.
Local Data
Local GroupWise data primarily consists of two elements, personal address book and GroupWise archives. In both cases, a decision must be made as to whether or not to convert this data as part of the migration. From an economic standpoint, migrating local data is more costly than migrating server-based data. There are a number of reasons for this, but the two key cost drivers are the process of collecting the data and the availability of tools to complete the migration.
Migration Options
Available options for handling Local Data include the following:
- No Migration – In this scenario, the local data is simply not migrated at all. This is the least expensive option.
- User Migration – Under this scenario, the local data is migrated by the end user. A process is developed, documented and distributed to end users on how to migrate their local data after their workstations are migrated. This may be as simple as instructing the users to write down personal addresses and recreate these in the new system.
- Dual Access – Under this scenario, the GroupWise client is left in place on the users’ desktops in order to function as an interface for viewing this legacy local data. In some circumstances, the majority of the GroupWise client can be removed and the Exchange client configured to access both the Exchange and legacy GroupWise systems.
- Migration – Migrating local data involves migrating personal address book lists to Contacts within Microsoft Outlook/Exchange and conversion of GroupWise archives to Outlook PST files or to messages on the Exchange server. It should be stressed that a decision to migrate local data can be limited to a certain group within the organization and does not automatically extend to everyone.
Data Collection
Unlike server-based data that is stored in central locations, local data generally exists on the hard drives of individual users or is only accessible via the local API’s of the workstation (GroupWise address lists). Storage of this data within the network is possible and helps mitigate the issue of collection, but is generally not possible for mobile users and still only HELPS solve the issue, not eliminate it entirely. Because this local data is generally stored on user hard drives, companies must find a method of collecting and centrally storing this information in preparation for conversion, or convert the data as part of a workstation update.
Methods of solving this issue are summarized below:
- Network Logon – This solution involves using the network logon scripts or similar process to collect and centrally store this local data. The logon script searches the local computer logging onto the system for local data files of interest in the migration, identifies the source of these files and copies the files to a central store with some sort of identification that indicates the source of the files.
- User Initiated – This solution places the burden on the end users to identify and submit local data that they wish to be migrated to the new system. This can be done through a variety of means including emailing the data files in question or simply copying and saving them to a pre-determined network location
- Workstation Based – This solution packages the conversion of local data with an update to the workstation. This solution works best when a visit to the local workstation is required.
- Central Resource – The central resource approach is only valid for certain types of local data, in this case GroupWise personal address books. These personal address books are actually stored on the GroupWise server but are only accessible via a workstation API’s. Hence, this approach involves a central resource creating a profile for and logging onto the mailbox of each individual involved in migration in order to collect the required data.
Migration Process
Once the data collection issues are worked out, the final issue involves the actual process used to convert the local data. This process varies depending on the type of local data in question.
GroupWise Archives
There are a number of ways of converting GroupWise archives, including:
- Third-Party Tools – There are a number third party tools available for migrating GroupWise archive files directly to Outlook PST files. These tools are generally available for $1-$5 per seat.
- User Initiated – This process involves the end users importing their GroupWise archives back into their GroupWise mailboxes prior to data migration. The messages are then migrated as part of the mailbox migration process.
- Central Resource – This involves the collection of these archives to a central location. A central resource then imports these archives into a central GroupWise mailbox, migrates the information to a PST file, purges the messages from the GroupWise mailbox and repeats.
Personal Address Books
There are a similar variety of options for migrating personal address books.
- Third-Party Tools – There are a number of third party tools available for migrating GroupWise personal address books to Outlook Contacts. These tools are generally available for $1-$5 per seat.
- Dual Access – This scenario involves using Microsoft Outlook to import the Novell Personal Address Book entries and allows end-users, workstation update personnel or a centralized resource to perform this task. This necessarily involves leaving the GroupWise client, or at least components of it, on the workstation. Alternatively, a central resource could perform this task from a single, centralized workstation configured for the task. This procedure is covered in Microsoft Exchange 2000 online documentation under, Microsoft Exchange 2000 Server | Migrating to Exchange | How To… | Migrate Your Messaging System | Migrate from Novell GroupWise | Import the Novell PAB into Microsoft Outlook.
- Existing Tools – This involves utilizing free, existing tools in a three step process of export, conversion and import.
- Export – Export can occur in one of two ways. One method is to have the end users export the information themselves. The exported information could be stored locally or on a network share. Users would need instructions and/or training to perform these actions. Alternatively, a dedicated resource could perform the export. To do so, the dedicated resource would need access to everyone’s GroupWise mailbox (which could either be changing everyone’s passwords, knowing everyone’s passwords or potentially via proxy rights). Contacts are exported to a CSV file (comma delimited).
- Conversion – Conversion occurs via a simple CSV parsing tool that converts the CSV output from GroupWise into something that Outlook can import. Conversion could occur via the end users or via a dedicated resource. Users would need instructions and/or training to perform these actions. The dedicated resource would need access to the exported information (meaning that the users would need to save them to a dedicated network location)
- Import – Import could occur via the end users or a dedicated resource. Users would need instructions and/or training to perform these actions. The dedicated resource would need access to the converted information and permissions to log into each user’s Exchange mailbox.
Adjunct Email Services
Adjunct email services consist of those common and not-so-common services that are integrated into the email system. Such services include fax, unified messaging, web access, anti-spam, content filtering and mailing lists.
- Discovery – Discovery is typically straight-forward since these adjunct email services are typically “owned” and supported by the IT department.
- Implementation – Implementation of these services under Exchange is typically not difficult considering the tremendous amount of native features within Exchange and a number of third-party products. The specific implementation details of each service will vary according to the specific email environment within an enterprise.
|
|