Quest® GroupWise Migrator for Exchange

Version 3.7.0.35

Release Notes

June 2010

(Doc ID 175)

Welcome to GroupWise Migrator for Exchange

New and Enhanced Features

Resolved Issues and Enhancements

Known Issues

Upgrade and Compatibility

Other Recent Releases

Welcome to GroupWise Migrator for Exchange

Quest Software's GroupWise Migrator for Exchange is a coordinated set of software applications designed to facilitate a variety of migration strategies for organizations moving from Novell GroupWise to an Exchange 2010, 2007 or 2003 environment. The Quest applications are designed to complement Microsoft's Exchange Connector for GroupWise and Outlook deployment tools, and provide a project-scale approach to overall migration planning and management. GroupWise Migrator for Exchange can:

Extract user data from the GroupWise server to mailbox-enable user accounts in the Active Directory, and preserve users' current SMTP addresses in their new AD accounts.
Migrate users' mail, appointments, tasks, personal address books, personal distribution lists and frequent contacts from the GroupWise environment to the Exchange server or Outlook Personal Folders (.pst) files.
Migrate users' archives from GroupWise either to Outlook .pst files, or to the new server.
Copy each user's GroupWise folder hierarchy into Exchange, and migrate the permissions that facilitate the sharing of folders.
Set and remove mail-forwarding rules between GroupWise and Exchange to assure correct mail routing throughout the transition period.

In a typical scenario, an administrator uses the GroupWise Migrator for Exchange batch-migration program to migrate groups of dozens of users at a time. But the Quest applications also contain a per-desktop migration program that lets an administrator visit individual desktops to perform migrations one user at a time, or end users can run the same per-desktop program to perform their own migrations. For that matter, an administrator can mix-and-match these strategies: migrating some users in batches, but others individually at their desktops, while still other users run the per-desktop tool themselves.

Quest's GroupWise Migrator for Exchange supports several such operational options that allow considerable flexibility in devising and implementing a suitable migration strategy for almost any set of circumstances and preferences.

GroupWise Migrator for Exchange, together with Microsoft's Exchange Connector and Outlook deployment tools, can perform or facilitate every administrative task associated with a GroupWise-to-Exchange migration. Meanwhile, the accompanying Quest documentation provides a truly project-scale approach to migration planning and management, with a comprehensive, broad-context checklist of pre-migration planning topics, and broad-context process instructions that explain how the Quest tools fit into the overall flow of a variety of migration scenarios.

New and Enhanced Features

The following new and enhanced features have been introduced in this release:

GroupWise 8.0.0 and 8.0.1 support: GroupWise Migrator for Exchange now supports GroupWise versions 8.0.0 and 8.0.1 as source messaging systems and end-user workstation clients.
Control of identity parameter for the Update-AddressList cmdlet: An admin can now specify the name of the identity parameter for the Update-AddressList PowerShell cmdlet, which the batch migrator runs after mailbox-enabling a collection if [Exchange] RunUpdateAddressList=1. (Actually this feature was added to GME version 3.x, but had not previously been documented.) The name can be specified by a new AddressListName= parameter in the [Exchange] section of gwmigapp.ini. If unspecified, the value defaults to "All Users." These parameters have been added to the updated GME Program Parameters Reference that accompanies this release.
Control of identity parameter for the Update-EmailAddressPolicy cmdlet: An admin can now specify the name of the identity parameter for the Update-EmailAddressPolicy PowerShell cmdlet, which the batch migrator runs after mailbox-enabling a collection if [Exchange] RunUpdateEmailAddressPolicy=1. (Actually this feature was added to GME version 3.x, but had not previously been documented.) The name can be specified by a new AddressPolicyName=<NameOfPolicy> parameter in the [Exchange] section of gwmigapp.ini. If unspecified, the value defaults to "Default Policy." These parameters have been added to the updated GME Program Parameters Reference that accompanies this release.
Control of AD mAPIRecipient property: GME now lets an admin control whether and how the AD Object Merge Tool will set AD's mAPIRecipient property. Previously the Merge Tool always left the AD attribute set to its default <not set>, but two new boolean program parameters in the [ActiveDirectory] section of the adobjmerge.ini file now let you control the setting:

[ActiveDirectory]
UseMapiRecipientFlag=<#>
MapiRecipientFlag=<#>

//  boolean, default=1
//  boolean, default=1

In adobjemerge.ini, the UseMapiRecipientFlag= parameter tells the program whether to set the AD property according to the MapiRecipientFlag= parameter value. If UseMapiRecipientFlag=0, the program will leave the AD property at its <not set> default. If UseMapiRecipientFlag=1, the program will set the AD property according to the MapiRecipientFlag= parameter value: MapiRecipientFlag=1 sets the AD property to TRUE, while 0 sets it to FALSE. Note: If UseMapiRecipientFlag=1 and Provision Users if not found is selected, the AD Object Merge Tool will set AD's mAPIRecipient to FALSE.
      Important: The same parameters must also be set to the same values in the [ActiveDirectory] section of the gwmigapp.ini file, so that the Admin-Driven Batch Migrator can correctly set the mAPIRecipient property when that program is run to mailbox-enable users. All of these parameters have been added to the updated GME Program Parameters Reference that accompanies this release.

For new and enhanced features in other recent releases, see Other Recent Releases

Resolved Issues in This Release

None in this release.

CR #86006 CR #81226	The ExportRTF= boolean parameter (in the [GroupWise] section of gwmigapp.ini) now lets you choose between preserving UTF-8 characters (ExportRTF=0) or preserving RTF (non-UTF-8) text (ExportRTF=1) in a message body.
CR #79687	A code refinement has dramatically improved performance when the migration program is gathering statistics while migrating a particularly large mailbox.

Known Issues

Most of the known limitations of any migration process are due to feature inconsistencies between the source and target environments. That is, features that are available in the source environment simply cannot be migrated to a target environment that does not offer the same or comparable features. Other limitations are due to feature incompatibilities, where similar features are available in both the source and target environments, but their implementations are so different that the migration may be impractical. In any case, most administators regard these sorts of limitations as trivial or incidental to an overall migration project.

An appendix of the GME Pre-Migration Planning Guide provides a list of those sorts of Known Limitations, which we do not expect to resolve any time soon. Other known issues associated with this particular release are listed here:

CR #86496	Applying a date filter to a migration can greatly reduce throughput (processing rate) unless the Log Level is set to 3.
CR #76164	The GroupWise Directory Exporter does not export nicknames, although it does export aliases. (Aliases and nicknames are different data elements.)

Upgrade and Compatibility

There is no need to uninstall the previous version before installing the new version. The upgrade installation and setup will be fully automated, and will preserve any data already migrated by an earlier version, so that you may simply resume the migration process from wherever you left off with the previous version.

System Requirements

GroupWise Migrator for Exchange requires the installation and configuration of several components on various machines: the source GroupWise server, the destination Exchange server, the admin's migration workstation (sometimes two or more admin workstations), and end-user client desktops. In addition to the Quest components, a migration requires the installation and proper configuration of other, non-Quest applications including the GroupWise and Exchange servers, Active Directory, and the GroupWise and Outlook clients. The full installation and configuration requirements are therefore more detailed than the requirements summary provided here. See the GroupWise Migrator for Exchange Quick-Start Guide for complete System Requirements, including tips for how to get multiple applications from different vendors to cooperate when installed on a single admin workstation.

This list specifies the basic minimum hardware and software requirements for GroupWise Migrator for Exchange:

On the GroupWise server:	Must be running Novell GroupWise version 5.5.3 to 7.0.3, or 8.0.0 or 8.0.1. If GroupWise Internet Addressing is not enabled, GroupWise Internet Agent LDAP Service must be configured to automate the creation of the Address Translation Table. For more information, see: http://www.novell.com/documentation/lg/gw55/index.html?gw55ia/data/a2zuwkc.html.
On the Exchange server:	Must be running Exchange 2010, Exchange 2007 (SP0, SP1 or SP2), or Exchange 2003, except: direct migration from GroupWise 5.5 to Exchange 2010 is not supported.
On each administrator workstation (running the GroupWise Migrator for Exchange admin components):	Workstation OS must be a 32-bit version of Windows XP SP2 or higher, or Windows 2003 Server SP1 or higher, or Vista Enterprise Edition. GME does not support a 64-bit OS. If migrating to Exchange 2007 or 2010, the workstation OS must be a US English edition. Workstation must be a separate machine from the Exchange server, but a member of the same domain as AD and Exchange, and meeting these minimum hardware requirements: 1+ GHz processor. 1GB memory. 20GB free disk space. Recommendations for improved performance, especially for high-volume migrations: 3+ GHz processor. 2GB memory. 1 Gbps NIC. 1 Gbps or faster network connections among all migration workstations and the Exchange and GroupWise servers. The Novell NetWare Administrator program (NWAdmin or ConsoleOne) must be installed. The Novell client for NetWare (client version 4.7 or higher, 4.91 SP2 recommended), and the GroupWise client must both be installed. *Required for migration to Exchange 2010 (only):* Windows PowerShell 2.0 (a component of Windows Management Framework, available at this writing at this Microsoft link). Note: Depending on your environment, you may need to run this command to enable the PowerShell layer using remote PowerShell: get-executionpolicy \| set-executionpolicy unrestricted *Required for migration to Exchange 2007 (only):* Exchange 2007 or E2007 SP1 Management Tools (32-bit version, US English only), which in turn requires: .Net Framework 2.0, Microsoft Management Console (MMC), and Windows PowerShell. The 32-bit version of Exchange 2007 Management Tools is available (at this writing) at this Microsoft link, and see also Microsoft's installation instructions. *Required for any Exchange 2003 administrative functions (only):* Windows Admin Tools (adminpak.msi). Exchange System Manager (version to match the installed version of Exchange). *Required for ALL destination Exchange versions:* Outlook 2000, 2002, 2003 or 2007 must be installed, with these qualifications: Outlook 2003 and 2007 are incompatible with GroupWise 5.5. If migrating from GroupWise 5.5, then Outlook 2000 or 2002 is required—not 2003 or 2007. Outlook 2000 and 2002 are incompatible with Exchange 2010. If migrating to Exchange 2010, then Outlook 2003 or 2007 is required—not 2000 or 2002. The MAPI DLLs required to perform a migration must be those that are part of Outlook, not the downloadable Exchange 2007 "server" MAPI.
On user desktops (if running the SSDM):	Must be running Microsoft Windows 2000 (or higher). Must be running Outlook 2000, 2002, 2003 or 2007, with these qualifications: Outlook 2003 and 2007 are incompatible with GroupWise 5.5. If migrating from GroupWise 5.5, then Outlook 2000 or 2002 is required—not 2003 or 2007. Outlook 2000 and 2002 are incompatible with Exchange 2010. If migrating to Exchange 2010, then Outlook 2003 or 2007 is required—not 2000 or 2002. Must be running a GroupWise client version 5.5.3 to 7.0.3, or 8.0.0 or 8.0.1.
All machines:	Must have network access.

Global Operations

This section contains information about installing and operating this product in non-English or non-ASCII configurations, such as those needed by customers outside the USA. This section does not replace the materials about supported platforms and configurations found elsewhere in the product documentation.

The platforms and configurations supported in this release may use any time zone, single-byte character encoding, language, or locale configuration to operate this product. Multibyte encodings (such as those used for the Chinese, Japanese, or Korean languages) may work appropriately but have not been tested and this product should be used with caution in those environments.

The migration server must be installed and operated on a machine where the code page associated with the runtime locale is identical to the encoding for each mailbox being migrated. The Groupwise APIs used to retrieve the data do not support retrieval of data from outside the current code page. For example, if the migration server were configured on a German machine (which uses code page 1252) and used to migrate a mailbox containing Polish data (which uses code page 1250), data would be lost during the migration.

The Exchange server which is a target for the migration may be in any locale, as that interface uses the Unicode character set.

Getting Started

Contents of the Release Package

Upon installation, the GroupWise Migrator for Exchange (GME) product package contains the following component applications, accessories and documentation files:

Quest GME components:
- Directory Exporter
- AD Object Merge Utility
- Administrator-Driven Batch Migrator
- Self-Service Desktop Migrator
- AddProxy Utility
- Log Viewer
Quest GME product documentation:
- Release Notes (HTML document)
- PDF-format documents:
  - Quick-Start Guide: QStartGuide.pdf
  - Pre-Migration Planning Guide: GMEPreMigrationPlanningGuide.pdf
  - Administration Guide: GMEAdminGuide.pdf
  - Self-Service Desktop Migrator User Guide: SSDMUserGuide.pdf
  - Program Parameters Reference: GME_INI_Reference.pdf
- On-line Help systems (compiled HTML Help files):
  - gwdirapp.chm (for the Directory Exporter)
  - adobjmerge.chm (for the AD Object Merge Utility)
  - gwmigapp.chm (for the Admin-Driven Batch Migrator)
  - gwdtapp.chm (for the End User-Driven Migrator)
  - wlogview.chm (for the Log Viewer)

Installation Instructions

Refer to the GME Quick-Start Guide for installation instructions.

Upgrading from an Earlier Version

When upgrading GroupWise Migrator for Exchange, you may simply install the newer version over the older one. It is not necessary to remove any files or uninstall the previous version.

The upgrade installation and setup are fully automated, and will preserve any data already migrated by an earlier version, so that you may simply resume the migration process from wherever you left off with the previous version.

For More Information

Contacting Quest Software:

Email	info@quest.com
Mail	Quest Software, Inc. World Headquarters 5 Polaris Way Aliso Viejo, CA 92656 USA
Web	http://www.quest.com

Refer to our Web site for regional and international office information.

Quest Support:

Quest Support is available to customers who have a trial version of a Quest product or who have purchased a Quest product and have a valid maintenance contract. Quest Support provides unlimited 24x7 access to SupportLink, our self-service portal. Visit SupportLink at http://support.quest.com.

From SupportLink, you can do the following:

Retrieve thousands of solutions from our online Knowledgebase
Download the latest releases and service packs
Create, update and review Support cases

View the Global Support Guide for a detailed explanation of support programs, online services, contact information, policies and procedures. The guide is available at: http://support.quest.com.

This document contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of Quest Software, Inc.

Quest, Quest Software, and the Quest Software logo are trademarks and registered trademarks of Quest Software, Inc. in the United States of America and other countries. For a complete list of Quest Software’s trademarks, please see http://www.quest.com/legal/trademark-information.aspx. Other trademarks and registered trademarks are property of their respective owners.

If you have any questions regarding your potential use of this material, contact:

Quest Software World Headquarters
LEGAL Dept
5 Polaris Way
Aliso Viejo, CA 92656
Email: legal@quest.com

Disclaimer

The information in this document is provided in connection with Quest products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest products. EXCEPT AS SET FORTH IN QUEST'S TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Quest does not make any commitment to update the information contained in this document.

Other Recent Releases

New & Enhanced Features and Issues Addressed in Version ...

3.6.2.x: 3.6.2.14 • 3.6.2.13 • 3.6.2.9

3.6.1.x: 3.6.1.73

3.6.0.x: 3.6.0.37 (initial 3.6 release)

3.5.2.x: 3.5.2.14 • .2

3.5.1.x: 3.5.1.57 • .56 • .54 • .41 • .38 • .36 • .35 • .31 • .30 • .29

3.5.0.x: 3.5.0.16 • .12 (initial 3.5 release)

Version 3.6.2.14

New and Enhanced Features in Version 3.6.2.14:

Message retry feature for GroupWise connection: GME now lets you configure the Admin-Driven Batch Migrator to retry the migration of an entire message when an error occurs in the connection between GME and the GroupWise server. (The other message-retry feature, introduced in version 3.6.2.13, did the same thing for errors that occurred between GME and Exchange.) Now, if a GroupWise-GME connection error causes an entire message to fail, these message-retry parameters let you tell the program to retry processing the entire message, from the beginning, at specified intervals, through a specified number of iterations:

[GroupWise]
RetryCount=<#>
RetryDelay=<##>

// integer (number of retries after failure), default=3
// integer (seconds), default=30

The RetryCount= parameter tells the Admin-Driven Batch Migrator how many times to retry to migrate a message (if not successful on first attempt), at intervals specified by the RetryDelay= parameter, before giving up the attempts. The defaults, RetryCount=3 and RetryDelay=30, tell the program to retry three times (four total tries), at intervals of 30 seconds, and then give up if still unsuccessful. If a message fails again on the last attempt, GME notes the failure in its log and resumes processing with the next message.

Version 3.6.2.13

New and Enhanced Features in Version 3.6.2.13:

Message retry feature: GME now lets you configure the Admin-Driven Batch Migrator to retry the migration of an entire message when some error causes the overall message to fail. This feature can complement the MAPI-error retry feature introduced in version 3.6.2.9, which permits retries at the MAPI-error level. If a MAPI error remains unresolved after the specified number of retry attempts, GME notes the error in its log and resumes processing with the next element or property of the message. Now, if an error causes an entire message to fail, these message-retry parameters let you tell the program to retry processing the entire message, from the beginning, at specified intervals, through a specified number of iterations:

[Exchange]
WriteMessageTryCount=<#>
WriteMessageRetryWait=<##>

// integer (number of tries), default=1
// integer (seconds), default=30

The WriteMessageTryCount= parameter tells the Admin-Driven Batch Migrator how many times to try to migrate a message, at intervals specified by the WriteMessageRetryWait= parameter, before giving up the attempts. The default, WriteMessageTryCount=1, tells the program to try only once (and not re-try at all). If a message fails again on the last attempt, GME notes the failure in its log and resumes processing with the next message.

Version 3.6.2.9

New and Enhanced Features in Version 3.6.2.9:

MAPI error recovery: GME now lets you configure the Admin-Driven Batch Migrator to retry MAPI calls that return MAPI errors typically caused by network latency issues and/or poor bandwidth. Prior releases did not handle these errors because they did not occur in traditional migrations to local Exchange servers, but they are a problem now in migrations to remote "hosted Exchange" servers, such as Microsoft's BPOS. This new feature lets you tell GME to retry MAPI calls that return certain errors, since a series of retries is likely to "outlast" whatever condition caused the error, making the MAPI call likely to eventually succeed. The feature is configured by three new program parameters, all in the [Exchange] section of the gwmigapp.ini file:

[Exchange]
MessageRetryCount=<#>
MAPIRetryWait=<##>
MAPIErrorsToRetry=<########>

//  integer (number of retries), default=3
//  integer (seconds), default=30
//  string (MAPI error code/s, comma delimited), default=80040115

The MessageRetryCount= parameter tells the Admin-Driven Batch Migrator how many times to retry a MAPI call, at intervals specified by the MAPIRetryWait= parameter, before giving up the attempts, noting the error in the log, skipping the current item, and moving on to process the next item. The program will retry the call if its preceding attempt returns any of the error codes specified by the MAPIErrorsToRetry= parameter, and if the number of prior attempts is less than the MessageRetryCount= value. The default settings (retry 3 times, at 30-second intervals, for MAPI error 80040115 only) may dramatically improve success when migrating in a high-latency and/or low-bandwidth network.
The MAPIErrorsToRetry= parameter may contain multiple error codes, separated by commas, as in this example:

[Exchange]
MessageRetryCount=5
MAPIRetryWait=60
MAPIErrorsToRetry=8004010F,80040115

The example cited here (retry 5 times, at 60-second intervals, for MAPI errors 8004010F and 80040115) would make the program more persistent and patient, and for an additional error, compared to the feature defaults. Depending on your setting for Log level (on the Specify Run Information screen), the program's retry attempts may appear in the program logs with no other documented error or warning.

Version 3.6.1.73

New and Enhanced Features in Version 3.6.1.73:

Exchange 2007 SP2 support: GME now supports Exchange 2007 SP2 as a destination Exchange server.
Message Categories support (restored): GME again supports the migration of message Categories—color differentiation of messages within a folder, at the user's designation. (This feature is now restored to GME after having been briefly withdrawn from the product pending the resolution of a performance issue.) If the GroupWise source Category color does not exactly match one of Outlook's 25 standard colors, GME will assign it to the closest matching color. (GroupWise permits the designation of any color available in its RGB palette.) This feature is enabled by default, but can be disabled by setting this new boolean parameter value to 0:

[General]
DoCategories=<#>

... in the gwmigapp.ini file (for the Admin-Driven Batch Migrator) and/or in gwdtapp.ini (for the SSDM).

Note: Categories support requires GroupWise 6.5.7 or later on the admin's migration workstation.
Preservation of original GroupWise recipient list members: The Admin-Driven Batch Migrator can now preserve the original list-member recipients of a message sent (from GroupWise) to a distribution list. This feature expands the recipient list in GroupWise prior to migration—to yield the list members at the time the message was first sent, even if one or more members were later added or removed.
This is an optional feature, enabled or disabled by a new boolean program parameter in the [GroupWise] section of the gwmigapp.ini file:

[GroupWise]
AlwaysExpandRecips=<#>

The feature is off (0) by default, but may be enabled by setting AlwaysExpandRecips=1. If the feature is disabled, GME will migrate only the name of the distribution list as the recipient of the message, and a later expansion of the list name would not be an accurate list of recipients if list membership had changed since the message was originally sent.
Note that the size of a recipient list thus expanded may be limited by another program parameter that may accompany the AlwaysExpandRecips=1 parameter in the [GroupWise] section:

[GroupWise]
AlwaysExpandRecips=1
MaxExpandedRecips=<####>

... where <####> is an integer specifying the maximum number of recipients that GME will expand from a recipient list. (If the full list is longer than the specified max, GME will truncate the expanded list at that limit.) The value may be set to any positive 32-bit integer, and defaults to 5000, and should always match the maximum recipient list size in Exchange (which is 5000 by default).

Issues Resolved in Version 3.6.1.73:

CR #81143	The message bodies of posted and regular appointments containing two or more consecutive CRLFs followed by additional text no longer lose formatting or any text characters upon migration.
CR #80079	The SSDM no longer crashes in certain environments migrating to Exchange 2010.
CR #79507	Japanese characters in an attachment name are no longer dropped.
CR #79370	The AD Object Merge Tool now preempts certain runtime errors by stripping x400 and x500 addresses from Contacts prior to its merge function, and then restoring them to the objects after the merge.
CR #79221	The inactivity timer, which tells the Admin-Driven Batch Migrator to abort a process if the destination server is unresponsive to a data transmission for a specified number of minutes, has been refined to be more "forgiving" when the process encounters a task that may be expected to require a longer period to complete.
CR #76284	When a message header lacks readable sender info, the Admin-Driven Batch Migrator now attempts to generate a serviceable reply-to address for a message by parsing the GroupWise FromText field (which sets the display value of the sender in the UI).

Version 3.6.0.37

New and Enhanced Features in Version 3.6.0.37:

Exchange 2010 Support: GME now supports migration to Exchange 2010. See the updated System Requirements for the configurations (both the target server and the admin's workstation) necessary to migrate to Exchange 2010.
Message Categories Support: GME now supports the migration of message Categories—color differentiation of messages within a folder, at the user's designation. If the GroupWise source Category color does not exactly match one of Outlook's 25 standard colors, GME will assign it to the closest matching color. (GroupWise permits the designation of any color available in its RGB palette.) Note: This feature requires GroupWise 6.5.7 or later on the admin's migration workstation.
Selective Address Book Merging: GroupWise address book contents can now be merged into a single Outlook folder selectively, by address-book name. (In previous releases, you could choose only whether to merge all address books or none.) The new selective-merging feature is controlled by a new parameter in the gwmigapp.ini file (for the Admin-Driven Batch Migrator) and/or in gwdtapp.ini (for the SSDM):

[General]
MergeAddressBookList=<Name1; Name2; Name3; ...>

... where Name1, etc. are the display names of address books you want to merge, separated by semicolons. Note: The address-book name values are both case-sensitive and space-sensitive.
The original "all-or-nothing" feature remains available by the same boolean parameter:

[General]
MergeAddressBooks=<#>

... where a value of 1 tells the program to merge all address books, and 0 (zero) tells the program to merge none. Note that MergeAddressBooks= should be turned off (0) if you want to use the MergeAddressBookList= selective feature. If MergeAddressBooks=1, then all address books will be merged regardless of the value(s) of the MergeAddressBookList= parameter.
If you use either parameter to merge one or more address books into a single folder, the destination folder will be Contacts unless you specify some other folder name by:
[General]
MergeAddressBookFolder=<FolderName>

Issues Resolved in Version 3.6.0.37:

CR #75689	The MaxLargePstSize= INI file parameter now supports values greater than 2³² KB. This parameter specifies the maximum size (in kilobytes) of large PSTs (Outlook 2003 Unicode PST files), beyond which the program will split the file into two or more files.
CR #74709	The Admin-Driven Batch Migrator code has been refined to make inactivity timeouts less common. In addition to the code refinements, note that GME lets you enable or disable the inactivity timer, which tells the program to abort a process if it receives no response from the destination server for longer than a specified number of minutes following a data transmission. The inactivity timer is enabled or disabled by this boolean program parameter in the [General] section of gwmigapp.ini: [General] DoInactivityTimer=0 The feature is on (1) by default, or set the value to 0 (zero) to turn it off. For very large (multi-gigabyte) mailboxes, you may want to disable the timer altogether (DoInactivityTimer=0), and let the program run overnight. If the program still appears to be hung the next day, you could then manually abort the run. The number of minutes the timer should wait is set to 40 by default, but you can specify some other value by this parameter, also in the [General] section of gwmigapp.ini: [General] InactivityTimeoutMinutes=<##>
CR #61223	The recipient-notification message that accompanies a migrated shared address book now identifies the Sender as "Migration Administrator" rather than "unknown [.]," as in prior releases.
CR #33954	An attempt to open a special Root folder no longer generates an Unable to open... warning.
CR #75688	HTML emails that contain some accented non-English characters are now correctly rendered with Western-European encoding.
CR #75485	GME now supports Norwegian-language Exchange default folder names.

Version 3.5.2.14

New and Enhanced Features in Version 3.5.2.14:

Greater control over inactivity timeouts: GME now lets you enable or disable the batch-migrator program's inactivity timer, which tells the program to abort a process if it receives no response from the destination server for longer than a specified number of minutes following a data transmission. The inactivity timer is now enabled or disabled by a new boolean program parameter in the [General] section of the gwmigapp.ini file:
The feature is on by default (DoInactivityTimer=1), or set the value to 0 (zero) to turn it off.

The number of minutes the timer should wait is set to 40 by default, but you can specify some other value by another new program parameter, also in the [General] section of the gwmigapp.ini file:
These new parameters do not yet appear in the GME Program Parameters Reference, but will be added for the next release.

Issues Resolved in Version 3.5.2.14:

CR #74709	Code enhancements have eliminated confusing log entries for API AlarmTime access issues, in the logs for both the Admin-Driven Batch Migrator and the SSDM.
CR #69336	Archive default folder names that contain vowels with umlauts (e.g., German ä, ö, ü, etc.) now migrate to the correct folder names.
CR #68364	The Directory Exporter now correctly processes a particular address object that had triggered an error in the prior release.
CR #66865	The Admin-Driven Batch Migrator now correctly migrates a certain type of large archive that failed to migrate in the prior release.
CR #65830	The GME installation program now correctly displays Quest License Key characters that appeared as generic "block" characters in the prior release.
CR #71060 CR #69656	The GME Program Parameters Reference has been updated to document the RemigrateMode=, MigrateCalData=, and MergeFindbySMTP= parameters.
CR #70313	The GME Pre-Migration Planning Guide has been updated to document the recently added "smart remigration" features, in the new Remigration section of chapter 3 ("Other Strategic and Tactical Issues").
CR #69279	All documentation references to the file previously named GroupsToProvision.abk have been changed to GroupsToProvision.txt, to match the new name of the file as the Directory Exporter now generates it.
CR #65939	The GME Administration Guide now explains how Organization Objects are used in GroupWise. In chapter 5, see the pushpin note in the section for the Specify Data for Migration screen.
CR #68139	The GME Administration Guide has been updated to note an important pre-run consideration for the SSDM. This note now appears as a caution in the Per-Desktop Migrations section of chapter 1 (The Migration Process): The SSDM requires access to the AddressTranslation.csv and AddressTranslation.bin files, generated by the GME Directory Exporter, to convert addresses in messages, address books, and frequent contacts to the appropriate Internet address for each user. Make sure that all users have access to the share that contains those files, in your Quest programs folder. These files are generated by the GME Directory Exporter, so if they do not exist you will have to run the Directory Exporter to create them.
CR #71007 CR #68444	The GME Administration Guide has been updated to add these recently identified issues to the Known Limitations (in Appendix A): The Admin-Driven Batch Migrator and SSDM do not preserve internet headers in migrated messages. GME does not migrate the My Subject field on the Personalize tab of a message.

Version 3.5.2.2

New and Enhanced Features in Version 3.5.2.2:

Documentation enhancements — The GME documentation has been substantially reorganized and updated—for content improvements generally, but also in an effort to make the documentation more useful to administrators who prefer to take on a migration project with minimal or no help from outside consultants. Highlights of this effort include:
- Split the old User Guide into two separate PDF documents (which now replace the User Guide), to separate the hands-on operating instructions and application notes for product components from the more theoretical, conceptual topics for pre-migration planning. The two new documents are the Pre-Migration Planning Guide, and the Administration Guide. (The Help files and SSDM User Guide are unaffected by these changes.)
- Update, clarify, and elaborate on pre-migration planning factors, especially coexistence options and migration scale.
- Provide flow charts to visually illustrate the pre-migration and migration processes, and provide more information in table form.
- Clarify the three basic migration scenarios—coexistence by Connector, coexistence by SMTP, and no coexistence—and more clearly associate these scenarios with the conditional steps of the pre-migration and migration processes.
- In the new Administration Guide, for each component tool of GME, briefly articulate "Why and When To Use ..." the component, and briefly explain how to determine or test whether the component worked correctly.
- Reorganize GME documentation contents overall, to better integrate newer features and topics into the main body of the docs rather than "patched" on as appendixes, etc.

Issues Resolved in Version 3.5.2.2:

CR #66447

Code refinements in the Admin-Driven Batch Migrator have eliminated an error that occurred when processing a message with certain characteristics.

Version 3.5.1.57

Issues Resolved in Version 3.5.1.57:

CR #66056

GME now searches the original MIME (mime.822 attachment) for text/html bodypart’s Content-Type header and gets the character set from there when possible.

Version 3.5.1.56

Issues Resolved in Version 3.5.1.56:

Character Encoding: The migration programs now migrate messages set to the correct character encoding when an HTML body doesn't have an HTTP-EQUIV/Content-Type tag to indicate what its encoding should be. In prior releases, GME explicitly set the encoding of such messages to UTF-8 (65001) by default, which rendered some messages in the wrong character set.

Version 3.5.1.54

New and Enhanced Features in Version 3.5.1.54:

Free/Busy synchronization from GroupWise to Exchange through GroupWise Connector: The legacyExchangeDN can now be maintained through merging and mailbox-enabling, to support free/busy synchronization from GroupWise to Exchange through the GroupWise Connector. To remove the free-busy properties to stop Exchange from looking in GroupWise for users' free-busy information, you must select Remove Forwarding in the Exchange Administrative Operations (in the Admin-Driven Batch Migrator). This also removes the free/busy forwarding, and is required even if mail-forwarding is not set. For example, the default setting:

[ActiveDirectory]
AlwaysUseOldExchDn=1

... tells the AD Object Merge Tool and Admin-Driven Batch Migrator to maintain the legacyExchangeDN through merging and mailbox-enabling. This feature is on (1) by default, but can be disabled by AlwaysUseOldExchDn=0.
New AD Object Merge parameters set AD userAccountControl attribute: Two new program parameters for the AD Object Merge Tool now let you tell the program to set the userAccountControl attribute value in Active Directory:

[ActiveDirectory]
SetUserAccountControl=<#>
UserAccountControl=<###>

// default = 0
// default = 512 (NORMAL_ACCOUNT)
- SetUserAccountControl= is a boolean parameter that simply tells the program whether or not to set the value.
- If SetUserAccountControl=1, the UserAccountControl= parameter then sets the value with an integer.
- If SetUserAccountControl=0, the UserAccountControl= parameter is ignored.
New parameters let you create mail-enabled objects when none found in user list: Three new program parameters in the [ActiveDirectory] section:

[ActiveDirectory]
ProvisionUsers=<#>
UserContainer=<RelativeDomainName>
EnableUsers=<#>

//  default = 0
//  default = [none]
//  default = 0

ProvisionUsers=1 tells the AD Object Merge Tool to create a new mail-enabled object in AD when none is found by the program to correspond with a user in the user list. Such new objects will be created in the container specified by the UserContainer= parameter, also in this [ActiveDirectory] section. EnableUsers=1 tells the AD Object Merge Tool that users newly created by the program (if ProvisionUsers=1) should be logon-enabled. By default (EnableUsers=0), any such newly created users are not logon-enabled.
New parameters control adding new contacts for groups members not found in AD: Three new program parameters for the Admin-Driven Batch Migrator now let you control whether and how the program will define a new contact for a group member who cannot be found in Active Directory:

[ActiveDirectory]
CanAddGroupMembers=<#>
CanDeleteGroupMembers=<#>
GroupContactsContainer=<ContainerRDN>

//  default = 0
//  default = 0
//  default = none
- CanAddGroupMembers=1 tells the program to define a new AD contact for a group member not found in AD, and then add the contact as a new member to the corresponding AD group.
- CanDeleteGroupMembers=1 tells the program to synchronize any previously provisioned group in AD to match the current state of the corresponding group in GroupWise.
- The GroupContactsContainer= parameter specifies a relative domain name (relative to [ActiveDirectory] GroupsRDN=, which in turn is relative to the default naming context of the domain) to identify the sub OU in AD where new Contacts will be created if CanAddGroupMembers=1.
Directory Exporter now collects given names and surnames: The Directory Exporter now collects given names and surnames from the GroupWise source directory and reports them in two new columns in its .csv data file.
Documentation enhancements:
- Several new program parameters, introduced in this and other recent releases, are now documented in the updated GME Program Parameters Reference that accompanies this release.
- A new Summary of Features and Capabilities table has been added to the GME User Guide, as a new Appendix H.
- A new process flow chart, illustrating the overall GME migration process, has been added to the GME User Guide, as a new Appendix I.
- The Glossary, which appears in the User Guide, Quick-Start Guide, and all Help files, has been updated and expanded with a few new terms and clarifications of some existing terms.
- Two new Known Limitations have been added to the GME User Guide's Appendix G.

Issues Resolved in Version 3.5.1.54:

CR #31391 CR #60673	The Admin-Driven Batch Migrator and AD Object Merge Tool now prompt for a separate GC and DC (in the Active Directory Information screen), to preempt occasional errors that occurred in earlier releases. The code enhancements for this fix also provide greater specificity of error codes to help diagnose any related errors that do still occur.
CR #60331	The Admin-Driven Batch Migrator now correctly sets the charset of a migrated message HTML message body by reading the HTML body header to set the PR_INTERNET_CPID property.
CR #43788	The Admin-Driven Batch Migrator can again mailbox-enable non-mail users in Exchange 2007.

Version 3.5.1.41

Resolved Issues in Version 3.5.1.41:

CR #57587	SkipCountByFolder= parameter default is changed (Program Parameters Reference): The SkipCountByFolder= program parameter default has been changed from 0 to 1.
CR #57747	Admin-Driven Batch Migrator now migrates all Distribution List members: The Admin-Driven Batch Migrator now migrates all members of a Distribution List. An inadvertent limit in a prior release cause the program to migrate only 2000 members, but that limit has been removed.

Version 3.5.1.38

Resolved Issues in Version 3.5.1.38:

CR #43707

Character encoding now migrates correctly: The migration applications now correctly detect and set the character encoding of migrated messages, so that messages are rendered in the correct character set.

Version 3.5.1.36

New Features in Version 3.5.1.36:

Support for Exchange 2007 SP1 and its Management Tools — GroupWise Migrator for Exchange now supports Exchange 2007 SP1 and its Management Tools on the administrator's migration workstation.

Resolved Issues in Version 3.5.1.36:

CR #46631

Primary SMTP proxy address now retained after removing forwarding: The Admin-Driven Batch Migrator no longer removes the SMTP proxy address when removing forwarding.

Version 3.5.1.35

Resolved Issues in Version 3.5.1.35:

CR #44696	New parameter prevents incorrect aliases during mailbox-enabling: A new INI parameter lets you control the time interval between two subfunctions of the Admin-Driven Batch Migrator process for mailbox-enabling, which might otherwise generate incorrect aliases where Active Directory accounts are replicated among multiple servers. The program disables mail for an account before it creates the mailbox, but the mail-enabled account can appear to still exist for a few seconds on any servers where the account is replicated. When the program sees a not-yet-disabled account on the other server, it mistakenly treats the new mailbox as a duplicate, appending the digit "1" to the alias to differentiate it from the other account. If your AD accounts are replicated on multiple servers, and you experience this "Alias1" problem when enabling mailboxes, use the CreateMailboxDelay= parameter (in the [Active Directory] section of gwmigapp.ini), to force a delay between the mail-disabling function and the mailbox creation, to allow enough time for other servers to catch up and disable their replicated accounts. The parameter value defines a delay in seconds, in a valid range from 0 to 30000, and defaults to 0. For example: [ActiveDirectory] CreateMailboxDelay=15 ... tells the program to wait 15 seconds after mail-disabling an account before creating the associated mailbox. Quest in-house testing suggests the resolution of this problem may require a delay as long as 33 seconds, but often much shorter. Experiment with shorter values to determine the delay required in your own environment.
CR #44970	New INI-file parameter permits optional conversion of contact into mailbox when mail-enabling: MBoxFromContact= in the [Active Directory] section of gwmigapp.ini tells the Admin-Driven Batch Migrator whether to convert a contact into a mailbox when mailbox enabling. This feature is off (0) by default, since in a typical scenario no contacts should remain after the AD Object Merging feature has run (to merge contacts into existing AD objects). The feature is enabled by MBoxFromContact=1, for some rare circumstances where that option is preferrable.
CR #40619	Merging, mailbox-enabling and provisioning groups when a single forest contains domains with different top-level domain names: The base DN in an ADSI search had previously been too specific for GCs that contain objects due to transitive trust, but the admin now has the option of not specifying a base DN at all.

Version 3.5.1.31

Resolved Issues in Version 3.5.1.31:

CR #37639

AD group provisioning errors resolved: A code enhancement has resolved group provisioning errors that previously occurred when the last character in a truncated samaccountname string happened to be an invalid samaccountname character.

CR #40221

"Offline" migration process documented: A new Appendix C in the GME User Guide explains how to perform an "offline" migration: a two-step process that first copies GroupWise data by the file system to an intermediate storage location, and then migrates the data from the intermediate location into Exchange. The offline migration option is useful if, for example, your source and target servers are physically far apart, and limited bandwidth and a large volume of mail make live data transmissions impractical.

Version 3.5.1.30

Resolved Issues in Version 3.5.1.30:

CR #39501	Migration of shared folders: Code enhancements have eliminated a problem with the optional feature to migrate a separate copy of a shared folder for each user who shared the folder in GroupWise.
CR #39669	Updates to GME Program Parameters Reference: Editorial enhancements to clarify one parameter and add another.

Version 3.5.1.29

Resolved Issues in Version 3.5.1.29:

CR #22461

Forwarding filter relaxed for "Out of Office" auto-replies: The forwarding filter for "Out of Office AutoReply" messages in a GroupWise 5.5 environment has been relaxed to catch messages with either "Out of Office" or "Out of the Office" in the Subject line. (Outlook 2003 dropped the word "the" from the Subject line.) This enhancement helps to prevent message looping between GroupWise and Outlook.

CR #22464

Server-mail Read/Unread status now preserved after migration: The Admin-Driven Batch Migrator and Self-Service Desktop Migrator now preserve server-mail Read/Unread status after migration by the password-access and trusted-API methods, when migrating from a GroupWise source version 6.5.1 or higher. In previous releases, the migration process "touched" each message in a way that changed all "Unread" status flags to "Read."

CR #22465

Directory Exporter now updates changed SMTP addresses of nested groups: When the SMTP address of a subgroup (a group that is a member of another group) has been changed in the AddressTranslation.csv file, a re-run of the Directory Exporter will now update the subgroup's address in the GroupsToProvision.txt file. In previous releases, changed addresses for nested groups were not updated.

CR #22628

AD Object Merge issues in Exchange 2007 resolved: Mail-enabling issues that generated AD Object Merge application errors and failures in some Exchange 2007 environments have now been resolved.

CR #22640

MboxFromContact= Program Parameter Restored: This parameter in the [Active Directory] section of gwmigapp.ini had been inadvertently disabled in the preceding version, but is now restored. MboxFromContact= tells the Admin-Driven Batch Migrator whether to convert a contact into a mailbox when mailbox enabling. This feature is off (0) by default, since in a typical scenario no contacts should remain after the AD Object Merge tool has run (to merge contacts into existing AD objects). The parameter permits the enabling of the feature by MBoxFromContact=1, for some rare circumstances where the option is preferrable.

CR #24356

Documentation enhancement: Adds cautionary "pushpin" note to GME User Guide (chptr 4, Specify How To Migrate Shared Information, Define Access Control Lists (ACL's)... field): The program will ignore a checkmark in this field if MigrateEmptyFolders=0 (in the [GroupWise] section of gwmigapp.ini), and [General] ACLRootVisibleOnly=0. Adds [General] ACLRootVisibleOnly= and [GroupWise] MigrateEmptySharedFolders= parameters to the GME INI Parameters Reference.

CR #25966

New GME Coexistence documentation: A new supplemental document has been developed to update and more fully explain coexistence options for a GME migration, including migrations to Exchange 2007.

CR #25970

New Solution topic added to Log Viewer database: A new Solution topic has been developed and uploaded for ERROR: [7496-21-5-00001D4A] Unable to login to GroupWise as user 'xxxxxx'.

CR #28137

Documentation correction: Previous editions of the GME User Guide mistakenly listed a "hybrid scheme" as a coexistence option, but that option has been removed from the documentation.

CR #30097

Shared calendar items now accessible: Shared calendar items are now accessible after migration by all to whom the item was shared.

CR #30098

New program parameter permits skipping empty shared folders: The MigrateEmptySharedFolders= parameter (in the [GroupWise] section of gwmigapp.ini) tells the program whether to migrate empty shared folders, if MigrateEmptyFolders=0 (telling the program to not migrate other empty folders). That is,

[GroupWise]
MigrateEmptyFolders=0
MigrateEmptySharedFolders=1

... tells the program to migrate empty shared folders, but to not migrate other (non-shared) empty folders. By default (MigrateEmptySharedFolders=0), empty shared folders are not migated. If MigrateEmptyFolders=1 (the default), the program ignores this MigrateEmptySharedFolders= parameter and migrates all empty folders.

CR #30099

New program parameter controls migration of shared-access folder ACLs: The AclRootVisibleOnly= parameter (in the [General] section of gwmigapp.ini) tells the program whether to migrate the ACLs of shared-access folders when MigrateEmptyFolders=0 (in the [GroupWise] section, telling the program to not migrate empty folders). If MigrateEmptyFolders=1, the ACLs are migrated and any AclRootVisibleOnly= parameter is ignored. The program will migrate shared-folder ACLs by default (ACLRootVisibleOnly=1), but you can disable the feature by:

AclRootVisibleOnly=0

Version 3.5.0.16

Resolved Issues in Version 3.5.0.16:

CR #22547	Outlook folder issues resolved: Reported problems with Outlook folder accessibility and the visibility of items within Outlook folders have been corrected. Some customers had reported being unable to move items into an Outlook folder after migration, but this problem is now resolved.
CR #22640	Group provisioning issues in Exchange 2007 resolved: In some network configurations, groups that had been provisioned into AD for an Exchange 2007 target environment were not mail-enabled as they should have been. This problem is now fixed.

Version 3.5.0.12 (initial release of version 3.5)

Updates in Version 3.5.0.12:

Per-desktop application renamed "Self-Service Desktop Migrator" - The per-desktop migration program, called the "End User-Driven Migrator" in previous releases, has been renamed to the "Self-Service Desktop Migrator."
Enhanced "silent mode" for Self-Service Desktop Migrator - The Self-Service Desktop Migrator now permits greater admin control over which screens and which fields will appear to the user in the GUI, and the values that will prevail for fields that are hidden from the user. These program customizations are accomplished by a set of INI-file parameters, documented in Appendix E of the GroupWise Migrator for Exchange User Guide.
Enhanced Log Viewer application - The Log Viewer now provides more detailed reports, an ordered listing of errors, with user list and the solution details from the solution website. Also, you can now optionally use the Log Viewer without contacting the Internet -- useful at sites that do not have or are blocked from Internet access.
More documentation for pre-migration planning - Chapter 1 of the GroupWise Migrator for Exchange User Guide now contains a much-expanded section on Pre-Migration Planning and Testing, with several new topics, and updated information and elaborations for most existing topics.

New Features in Version 3.5.0.12:

Exchange 2007 support - GroupWise Migrator for Exchange now supports migration to Exchange 2007, and mailbox creation with PowerShell for Exchange 2007 servers. GroupWise resources are now migrated to resource mailboxes in Exchange 2007.
GroupWise 7 support - GroupWise Migrator for Exchange now supports migration from GroupWise version 7.
"Smart" remigration by admin-driven batch migrator - The administrator-driven batch migrator now automatically detects if a GroupWise source item has been previously migrated, and if so will not create a duplicate item in Exchange. This feature can operate in either of two modes, determined by a boolean program parameter in the [Exchange] section of gwmigapp.ini:
[Exchange]
RemigrateMode=<#>

... where the parameter value is a single digit, 0 or 1:
- 0 (Update mode): If the program detects a duplicate message in Exchange, the message will be deleted in Exchange and then remigrated from the GroupWise source.
- 1 (default): If the program detects a duplicate message in Exchange, the GroupWise source will not be migrated, leaving the previously migrated copy in Exchange.
Log files now document system information - GroupWise Migrator for Exchange applications now log system information at the top of each log file, as appropriate (per application): versions of the Outlook and Groupwise clients installed on the migration workstation, versions of the GroupWise and Exchange servers, and versions of the Novell and GroupWise clients. (This feature will help Quest Support staff recreate a problem, to analyze and solve it.)
Documentation of mail-routing options for coexistence - The Pre-Migration Planning and Testing section of the GroupWise Migrator for Exchange User Guide now includes an explanation of mail-routing options for coexistence. The new material explains the advantages and disadvantages of mail routing and free/busy lookups via the Microsoft Connector vs. SMTP addressing vs. a hybrid scheme using both methods.
New Program Parameters documentation - The Program Parameters Reference, previously available only by separate download (under the title Program INI-Files Reference), is now included in the primary product kit and installed with the other documentation.

Resolved Issues in Version 3.5.0.12:

CR #[none]	Migration improvements: Embedded images for HTML messages are now displayed correctly in migrated messages. Checklist items now maintain their follow-up times and alarms. Migrated contacts now preserve multiple email addresses (up to three will be migrated).
CR #[none]	MAPI profile credentials now collected by GroupWise Migrator for Exchange: In previous releases, the Quest application let MAPI prompt for its own credentials, but in some circumstances the admin would be prompted to exit the application and then reenter the credentials. This problem does not occur now that the Quest application collects the credentials.
CR #[none]	New documentation help for coexisting applications on migration workstation: The System Requirements sections of the GroupWise Migrator for Exchange User Guide and Quick-Start Guide now include advice for how the multiple applications required on the admin's migration workstation can be installed in a particular order to minimize application conflicts and incompatibilities.
CR #[none]	Restored documentation section: A paragraph in the GroupWise Migrator for Exchange User Guide, offering suggestions for how an admin might distribute the per-desktop migration program, has been restored. The paragraph had been inadvertently deleted from the documentation in version 3.2.