| Sun Java System Connector for Microsoft Outlook 6.0 Desktop Deployment Administrator's Guide |
Chapter 3
Issues to Address in
Planning for a New Mail ServerThis section explains topics that should be addressed in the planning for every migration project.
Characterize Your Site Configuration(s) and UsersAre your users all in one physical, geographic location—all in one building? All on one floor? In one room? Or do you have a global headquarters in St. Louis, branch administrative offices in Tangiers, Barcelona and Oshkosh, and factories in Singapore and Tuscaloosa? In your current e-mail system, how many Exchange servers and users are at each location? After you migrate, how many Sun Java System servers will serve the users at each location?
In your current e-mail system, how are your users assigned to your various Exchange servers? By geography only? By administrative entities within your organization—for example, the Sales Department vs. the Engineering Department vs. Customer Service and so forth? Or by business unit or team—for example, the Product XYZ team vs. the Product ABC team?
What are the education and training backgrounds of your various users? How long have they been working with computers? To what extent are they likely to require administrator or help-desk “hand holding” during the migration?
User Grouping Criteria and ImplicationsDetermine the optimum number of your users to migrate at a time. Your optimum migration group size will depend in part on the volume of data per user on the server. Migration group size should be correlated to the size and availability of your enterprise help desk, since you can assume that at least some percentage of users will call the help desk for assistance.
Your first few migration groups should be smaller than your expected optimum size, since these first groups will likely expose any unforeseen issues with documentation, your communication plan, and so forth before a larger group would generate correspondingly larger consequences. The first few smaller migration groups will also help you predict the demand on your organization's help desk upon the later migration of larger groups.
Finally, it is usually helpful to migrate users in logical groups, related by business function or by administrative entity or proximity, so they can support one another through the process.
Desktop Installation MethodsThe Sun Java System Connector Deployment Toolkit contains a variety of tools with operational options that permit considerable flexibility in devising and implementing a suitable migration strategy for most any environment, circumstances and administrator preferences. The topics below describe the most common scenarios, and explain how Sun’s migration tools accommodate them.
Interactive User Installation (Self-Service)
The Sun Java System Connector Setup Wizard is designed to be straightforward for end users to run by themselves. The Setup Wizard can be placed on a file server, so it need not be individually installed on end-user workstations. However, the physical installation of the Java System Connector software on user desktops requires access privileges that often are disallowed to many or most end users. If any of your end users do not have installation privileges for their own desktops, you may choose either of the following strategies:
- Visit each user's workstation and use your own administrator privileges to physically install the software to the user's desktop.
- Use a configuration management tool, such as Microsoft's SMS, to “push” the software to multiple users' desktops (explained below in "Automated “Push” via SMS or Other Configuration Management Tools").
After the software has been physically copied to a user's desktop, the user can run the Setup Wizard to configure the software and convert existing Personal Folders (.pst) files.
End users who run the conversion program will provide their own credentials for the Sun Java System servers. This method therefore permits conversion of password-protected .pst files (see "Password-Protected Personal Stores in Outlook" below), and lets users specify which of their personal stores should be converted for use with the new Sun Java System Connector software. (Users can read unconverted e-mail messages, but cannot reply to them because unconverted addresses are unfamiliar to the new server. Users who have some personal stores that are very old, so that the need for a future reply is highly unlikely, may therefore opt to leave such files unconverted. The conversions can run in the background, freeing the user's computer for other work, but the process is likely to slow the performance of other applications.)
The significant downsides of interactive user installation are:
- Increased demand for support from your organization's help desk, which may be considerable depending on your users' technical skills and the complexity of your “before” and “after” network configurations.
- Time and effort you, as an administrator, would have to devote to visiting multiple user workstations to physically copy the software to the users' desktops (for users who are not authorized to perform that task for themselves).
Administrator Performs Installation at Users' Computers
You may want to let some users “self-serve” their own installations, as described above, but assign administrators to visit others' desktops to perform some or all of the installation and configuration tasks for them. This approach can ensure a smooth migration for top executives or less technical users who are ill-prepared to perform the tasks for themselves. Your Deployment Plan should address whether these sorts of administrator visits are warranted for any users in your organization, and for whom.
Automated “Push” via SMS or Other Configuration Management Tools
Software installation on user desktops requires access privileges that often are disallowed to many or most end users. Most administrators of such networks use a configuration management tool, such as Microsoft's SMS, to “push” the software to multiple users' desktops — a method that bypasses the requirement for user access privileges. If your network serves “locked-down” Windows environments, where end users cannot install software, this sort of automated configuration management can spare the administrator many visits to individual user desktops.
To accomplish a “push” distribution, you can use the Deployment Configuration Program to build two different bundled installation packages for each user, to be executed in succession. The first would perform the “push” installation of the necessary Sun Java System software, while the second would run an interactive process by which the user could make choices about the configuration of the installed software and the conversion of his or her own existing data files. This “push” method may even be used to completely automate the conversion process for end users, but would require some scripting since the package must be invoked with information specific to each end user (e.g., the user's Sun Java System credentials).
Your Deployment Configuration Program Reference provides instructions for using Microsoft's SMS to implement this “push” method of software distribution. The Reference also explains how to use command-line switches with an SMS script to fully automate the process by passing the necessary user passwords, for the user’s Personal Folders (.pst) files, to the desktop installation program.
Command-Line Switches for Desktop Installation
The Sun Java System Connector Setup Wizard supports command-line switches that may be used in combination with the other desktop installation methods described above, or with an SMS script as described in the Sun Java System Connector for Microsoft Outlook Deployment Configuration Program Reference (under “Application Notes for Special Circumstances”).
The installation package will support these command-line switches:
/USERNAME=xxx, where xxx is the username on the Sun servers
/PASSWORD=xxx, where xxx is the password on the Sun servers
/FULLNAME=xxx, where xxx is the display name of the user
/EMAILADDRESS=xxx, where xxx is the email address of the user
/DN=xxx, where xxx is the user DN on the Sun servers
/NEWPROFILENAME=xxx, where xxx is the name of the created profile
/SAVEPASSWORD=n, where n = 1 (save) or 0 (don't save)These switches will be useful if you are converting an Exchange profile:
Migration of Important Server Data: More Than Just MessagesYour old server contains valuable information about your users, and an efficient migration will extract and use this information to provision the user accounts on your new Sun Java System server. In addition to your users' old mail messages, your old server contains user calendars, tasks, and personal address books and contacts. The old server also contains user names, primary Internet addresses, Internet aliases, phone numbers, postal addresses, and even descriptive information such as users' departments, titles, and so forth, and also all of your enterprise's public distribution lists.
While a detailed account of server data migration is beyond the scope of this document, you should understand that your old server is a valuable data resource that can be mined to drive user provisioning on the Sun Java System, as well as changes in mail routing. Sun Professional Services can help you to understand and accommodate server data migration in your Deployment Plan, and other third-party companies offer both technology and consulting expertise to facilitate the migration of your server data.
Mail Routing During Transition Phase of Server MigrationNot all of your users will migrate from the old server to the new server at the same time. User accounts on the new server are created and provisioned prior to users' actual migrations. As such, user mailboxes with the same address will reside on both the old and new servers simultaneously during your transition period. Some temporary mail-forwarding rules must therefore be defined to make sure that your users' mail is correctly routed during the transition period.
Even if your organization is implementing new Internet addresses, the old addresses must be maintained on the old server because replies to older messages will be deliverable only if the users' old primary Internet addresses continue to deliver to the correct server. Since all Internet mail for a given domain must go to a single server, specified in an associated MX record, your organization must decide when it will update its MX record to point to the new Sun Java System server.
If the MX record is switched to the Sun Java System server at the beginning of the transition period, you must configure the Sun Java System server so that any mail it cannot deliver to a local mailbox will be sent to the corresponding mailbox on the old server. Moreover, as new users are provisioned on the Sun Java System server, you must define forwarding rules on the new server so that any mail that would normally be delivered to the new mailboxes will instead be forwarded to the corresponding user mailboxes on the old server. As each user migrates to the new server, you must then delete the first forwarding rule on the new server, and define a new rule on the old server to forward all of the user's mail to the corresponding Sun Java System mailbox.
On the other hand, if the MX record will point to the old server until the end of the transition phase, you must configure the old server to send mail it cannot deliver locally to the corresponding user mailboxes on the Sun Java System server. As users migrate to the new server you must then define new rules on the old server to forward mail sent by other users on the old server to the users' new accounts on the Sun Java System server.
Synchronization of Global Address Books During MigrationLarger organizations are likely to require weeks or months to complete a phased migration, and during your transition there will be some users on each of the two systems. Many organizations prefer that all users maintain access to an accurate enterprise directory (white pages, global address book), but accuracy will require regular synchronizations of the two servers' directories as employees are hired, transferred, terminated and so forth. Your Deployment Plan should therefore specify some mechanism for regularly synchronizing the two directories throughout your transition period.
Sun Professional Services can assist in addressing this issue. There are also several products available to perform directory synchronization.
New User IDs and Passwords for Sun Java System ServersMost network systems are designed to prevent people from discovering user passwords, and this is particularly true of Microsoft Exchange. These security safeguards make it impossible to automatically retain users' existing passwords as they migrate from the old server to the new.
Meanwhile, many organizations prefer to standardize the form of their Internet addresses, or to combine domains during their migration to the Sun Java System. An organization must therefore decide, in advance, how account names and Internet addresses will be derived, and how users' new passwords will be assigned.
The network administrator must also devise a method for communicating these user credentials to both the users and the corporate help desk. One common approach is simply to prepare an e-mail merge, just prior to a group's migration, so that each member of the migrating group receives his or her credentials independently, and just in time for the group's first logins to the new server.
Password-Protected Personal Stores in OutlookOutlook users can assign passwords to their Personal Folders (.pst) files, but the Sun Java System Connector Setup Wizard needs to open and modify these files in order to convert them for use with the new Connector software and the Sun Java System server. Your end users will therefore have to provide the passwords for any .pst files that they want to convert.
The Setup Wizard will automatically prompt users for the necessary passwords as they are needed, but obviously this will require user involvement that makes a Silent Mode setup impossible. If it is important for you to run the Setup Wizard in Silent Mode, users can be instructed to remove all such passwords during the conversion, or simply let the Wizard run with the passwords in place. If the Setup Wizard runs in Silent Mode and encounters a password-protected file, it will not convert the file, and will report that not all files were converted. Depending on the settings in your administrator's Deployment Configuration tool, the Setup Wizard may also log the event as an error.
