One of my customers wanted to migrate from cc:Mail to Exchange Server 5.5. I was responsible for the technical migration of data from cc:Mail to Exchange and for the automated deployment of Outlook 2000. During the pilot phase, I used the Outlook Deployment Kit (ODK) and batch files to install Outlook 98 and create the initial Outlook profile. Immediately after Microsoft released the production version of Office 2000, my customer chose to install Outlook 2000 instead of Outlook 98 because of Outlook 2000's improved printing capability and use of Contacts instead of the Personal Address Book (PAB). Furthermore, the customer didn't want to upgrade Outlook after completing the data migration.
The customer had standardized its workstations on Windows NT 4.0. The company was using Norton Ghost's Ghost Walker utility from Symantec to image machines and Novell's NetWare Application Launcher (NAL) to deliver applications to the user's desktop. During the pilot stage, the company made a few changes to its machines to accommodate logon into an NT domain.
One of the most important factors in developing an automated deployment process is to have the equipment used in the production environment readily available. Most of my customer's environment had a mix of three workstation types. Therefore, I had to work with a sampling of the three different machine types, and I had to test several logon IDs. The more your development environment matches the customer's production environment, the better the deployment will perform in the long run.
You might need to create several versions of the installation to accommodate the customer's needs. This project required six versions, each with subtle differences (e.g., the Exchange site server name) and separate builds for desktop and laptop computers.
Creating an Installation Package
You can use the tools in the Microsoft Office 2000 Resource Kit to create an installation package for Outlook 2000. You can also adapt the process and the steps to install other Office components or the entire Office suite. Here's what you do.
Step 1: Create a workstation with Office 2000 installed. You'll use this workstation to fine-tune the deployment. You'll probably be rebuilding this machine several times throughout the testing. Also, save any notes, setup information, and documentation on a file server.
Step 2: On a test server, install Office 2000 with the /a administrative setup option. This process copies all the Office 2000 files to a network installation point. Don't deploy this installation in the production environment because some Office components install on a first-run basis; that is, the feature doesn't install until the user tries to use it. If the original installation point isn't available when the user selects one of these components, Office prompts the user for an alternative location of the source files. Although users can select another source, they might not know where the installation files reside, and they'll have to call the Help desk to find out.
Step 3: Install the resource kit core tool set (orktools.exe) on the workstation you created in step 1. During this step, you install two important components this project uses: the Custom Installation Wizard (CIW) and the Profile Wizard. All the resource kit utilities install by default; however, you can choose to install only these wizards.
Step 4: Create a test account on the Exchange server. Create a profile for the test account, and launch Outlook on the workstation you created in step 1. Configure Outlook with the customer's preferred look and feel; you must have a thorough understanding of Outlook to perform the configuration. At this point, you're working directly from the Outlook 2000 user interface in Tools, Options and the toolbars (View, Toolbars, Customize), not the Messaging API (MAPI) profile components in Tools, Services. Some changes I made for my customer included removing the Send/Receive button on the Standard toolbar, adding the Advanced toolbar, and disabling the calendar cache.
Step 5: After you've configured the client options, run the Profile Wizard from the resource kit tool set (which you installed in step 3). The Profile Wizard captures the settings and changes you made in the Outlook client and creates an Office Profile Setting (OPS) file. The CIW incorporates this file to generate a custom build. This process is straightforward. Close all Office applications, and run the Profile Wizard on the workstation. However, I recommend that you change the location of the profile to the server you used in step 2. Also, rename this file to a descriptive name if you need several profiles. In my project, I used a combination of the Exchange Server site name, a description of the workstation type, and the revision number, as you see in Screen 1.
Step 6: Start the CIW. From the resource kit tool set on the workstation you created in step 1, start the CIW. The first screen gives you an overview of the tool.
The second screen, which Screen 2 shows, prompts you to enter the location of the Windows installer package (MSI) files that are part of the administrative installation of Office 2000. The two MSI files are the nuts and bolts of the Office 2000 settings. Choose the data1.msi file, which is for workstations.
On the Select the MST File to Save screen, I chose to create a new Windows installer transform (MST) file instead of opening an existing MST file. During the testing phase, I found that starting from scratch helped me keep track of the options I wanted to test. Enter the name of the new MST file in the window, as Screen 3 shows. To keep the different installation versions straight, I named the MST file the same as the OPS file I created earlier.
On the Specify Default Path and Organization screen, the wizard prompts you for the location where the Office program files will reside. I used the defaults (ProgramFiles\Microsoft Office) because the customer had chosen the default in previous Office versions.
If you don't change the installation's default on the Remove Previous Versions screen, you'll delete Office applications that you had no intention of deleting. As Screen 4, page 11, shows, I cleared all the check boxes except Microsoft Outlook 97 & 98.
In the Set Feature Installation States screen you see in Screen 5, choose which Office components to install during your automated deployment. In my project, the client didn't want to install any components other than Outlook, so I selected only the components I wanted in the Outlook installation, including Collaboration Data Objects (CDO). For the other Office components, I chose the Not Available option, but I didn't hide the components. Not Available means that if you run setup.exe manually from the installation point, you can install other Office 2000 components at that time. If you choose to hide the feature (by right-clicking it), the components won't be available for the users to select.
On the Customize Default Application Settings screen, enter the name of the profile you created in step 5. I cleared the Migrate user settings check box because the company's technicians wanted Outlook to create a baseline Outlook profile every time it created a new user profile.
On the Add Files to the Installation screen, specify files to add to the user's computer during installation. I listed the Private Mailing List to Distribution List utility and the files my customer needed to run the cc:Mail Archive Import utility. On the Add Registry Entries screen, enter Registry changes to suit your environment. In this installation, I didn't need to make entries on this screen. However, in another installation, I found it simple to export a Registry key and include it in the installation to add environmental variables in the build.
In the Add, Modify, or Remove Shortcuts screen, remove or add shortcuts to the Start menu. I removed all icons except the Outlook icon, and I added the icon for the cc:Mail conversion tools that the user will be running.
In the Identify Additional Servers screen, add a prioritized list of servers from which users can install Office components if the server on which you initially installed Office (i.e., the primary server) is unavailable. If the primary server is unavailable, MSI attempts to find an active server on that list. If MSI finds an active server, that server becomes the new primary server. If MSI doesn't find an active server, MSI prompts the user for the location of a server.
In the Add Installation and Run Programs screen, I didn't need to add programs to my installation. However, this section lets you run additional executable or batch files if you install Office.
In the Customize Outlook Installation Options screen, which Screen 6 shows, customize the user's profile and account information. I included information for configuring my customer's MAPI profile with access to Exchange Server and for setting up a Personal Folders file, as follows:
- Under General, I created the Profile Name as %USERNAME% and selected Overwrite existing profile.
- Under Services List, I chose the Microsoft Exchange Server service, the Personal Folders service, and the Outlook Address Book service.
- For the Exchange Settings, I used the %USERNAME% variable as the user's mailbox name. You need to enter the name of an Exchange server in the site. Because this build was for desktop (not remote) users, I didn't specify the location of an offline folders .ost file or a path to the offline address book.
- For Personal Folder Settings, the client chose to have personal folders stored on the user's network home directory. I also wanted to use the user's name for the name of the .pst file, so I again used the environmental variable H:\DATA\OUTLOOK\%USERNAME%.
On the Customize IE % Installation Options screen, I selected Do not install Internet Explorer 5 at the customer's request. The Modify Setup Properties screen lets you define how setup performs the installation. I changed OUTLOOKASDEFAULTAPP to = ALL and the REBOOT option to Force.
On the final screen, click Finish to create the new MST file for the installation. When the CIW completes the installation, it offers suggestions for a setup command line. Of the available switches, the Setup properties and the command-line switches are notable. If you specify a Setup command-line option that is also specified in the Setup settings file or in the MST file, the command-line option takes precedence.
Step 7: Create a batch file with the command line you'll use to deploy the client. The command line will generate a log of the setup process. I used the following command line in a batch file for my installation:
setup.exe TRANSFORMS=\\lab\ office2k\MDdesk1.MST/qn+setup.exe TRANSFORMS=\\lab office2k\MDdesk1.MST /qn+ /lwm+ C:\temp\Ol2ksetup.txt
Enter the command line on one line.
Step 8: Start the installation. I created an Object in NAL, which pointed to the batch file to begin the Outlook installation. The same technique will work if your customer has other options (e.g., WinINSTALL, Microsoft Systems Management Server—SMS) for automating software deployments. I also added a batch file to run newprof.exe, which creates the user's initial Outlook profile.
Ready to Roll
After you've completed this process in a test environment, you're ready to repeat the process in your production environment. If you're confident about your MST file settings and want to save time, you can copy the Office installation and the MST files to the production environment.
The CIW is a useful tool for deploying the Office suite within an organization. If you perform a little work up front, the wizard lets you deliver a consistent Office setup with ease.
