Desktop Installation Methods

The Sun Java System Connector Deployment Toolkit contains a variety of deployment options 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 email 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 Chapter 3, Application Notes for Special Circumstances, in Sun Java System Connector for Microsoft Outlook 7 2005Q4 Administration Guide.

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:

/OLDDOMAIN=xxx, where xxx is the Exchange domain
/OLDUSERNAME=xxx, where xxx is the Exchange user name
/OLDPASSWORD=xxx, where xxx is the Exchange password