The SSDM offers an optional silent mode of operation. Silent mode is commonly used to minimize end user involvement when SSDM is deployed, while maintaining the flexibility and other benefits of a distributed migration. When silent mode is configured, the migration team configures the application in advance within the gwdtapp.ini files to determine what will migrate, the target for each migrated data type, and the filters and other configuration elements for the migration. For example:
The SSDM application is typically installed and configured in a shared directory, and a link to the gwdtapp.exe file is sent to users so they can launch the application independently. Multiple configurations can be established in advance of the migration to meet the needs of a variety of user types, and separate links can be distributed so that different users launch different configurations of the application.
Various degrees of the silent option can be configured depending on the flexibility and control you want to provide to the user community. However, it is commonly configured to run as "silently" as possible—which means users can complete their migrations simply by entering their GroupWise credentials.
The remaining sections of this chapter explain how command-line switches and parameters in the gwdtapp.exe file can be used to configure silent-mode operation. The pertinent INI file parameters are also documented in the Migrator for GroupWise Program Parameters Reference.
If the SSDM is configured to skip certain screen displays, the program must have some other way to obtain the information that would otherwise be collected from fields on those screens. The SSDM can read and/or infer some entry values from the operating environment—from the Windows Registry and Outlook’s initialization files, etc.—and some values can be specified by command-line switches (see below). But some values can also be provided by parameters in the gwdtapp.ini file.
When an entry value is specified in the INI file, the value will appear as the default if the corresponding screen and option appear in the program run, or will simply be the prevailing value if the screen and option do not appear.
Any or all of the migration choices in the Specify Data for Migration screen can be specified in gwdtapp.ini by these parameters:
A parameter value of 1 sets the option to "yes" (the data type will be migrated if the screen does not appear), or sets the associated checkbox to be marked by default. A value of 0 sets the option to "no," or sets the associated checkbox to be unmarked by default.
If a feature is disabled by AppDoesXxxx=0 (see below), the corresponding MigrateXxxxx= parameter will be ignored. On the other hand, if AppDoesXxxx=1 in silent mode (MigrateWhat=silent), the program will automatically set the corresponding MigrateXxxx= parameter to 1. (Although if MigrateWhat=show or =skip, the AppDoesXxxx= setting has no effect on the MigrateXxxx= parameter.)
The most common use of these parameters is to provide entry values when SSDM is configured to skip the Specify Data screen—by MigrateWhat=skip or MigrateWhat=silent (see below).
If SSDM finds more than one eligible Outlook profile on the user’s computer, or doesn’t find any, the program displays a Select Profile screen to prompt the user to designate the profile to be converted. If one and only one eligible Outlook profile is found on the user’s computer, the program will simply assume it is the correct profile to convert, and the Select Profile screen will not appear.
The per-desktop program can be configured to skip the Select Profile screen, but in that case the program must be able to determine the correct Outlook profile to convert. The user’s Outlook profile can be specified in the [General] section of gwdtapp.ini by:
Alternatively, the user’s Outlook profile can be specified by appending the /tgtprofile switch to the Desktop Migrator on the command line, when the program is executed. (See near the end of this chapter for more information about this and other command-line switches.)
Remember too that the program will not need this ProfileName value if one and only one eligible profile will be found on each user’s workstation.