Provide Feedback on this Broadcast

Note This document is based on the original spoken WebCast transcript. It has been edited for clarity.

Barbara Thomas: Welcome, everyone. In today's session we're going to discuss recommended methods and the best practices surrounding the deployment of Microsoft® Office 2003 in the enterprise (slide 2). The session will also cover Office 2003 system requirements, as well as available deployment tools and utilities for facilitating your deployment.

Our agenda for today (slide 3) is the Office 2003 system requirements; Office 2003 setup sequence; taking advantage of the new Local Installation Source; creating and using an Administrative Installation Point, otherwise known as an AIP; methods for customizing Office 2003; methods for installing Office 2003; some multilingual deployment strategies; maintaining Office 2003 installations; a little bit about Office 2003 security; and troubleshooting your deployment.

The system requirements (slide 4) for Office 2003 are basically the same as they were for Office XP. You need a Pentium 233 MHz processor or higher; an operating system of Microsoft Windows® 2000 Service Pack 3 or later or Windows XP or later, and that would include, also, Windows Server™ 2003, which has recently been released. Please note, though, that we no longer support any of the Windows 98 or Windows Me systems, or even Windows NT® 4.0.

We need a minimum memory of 64 MB of RAM; 128 MB of RAM is recommended. The disk space required, of course, depends on the type of installation that you choose. If we choose Office Professional Edition 2003 with InfoPath™, which includes Publisher, it requires around 450 MB. Just the Professional Edition, which includes Publisher, requires around 420 MB. Standard Edition is 260 MB. And, as I just mentioned, the hard disk space usage varies depending on your configuration. If you choose to install all options, that's going to make the requirements a little bit higher.

There are some additional requirements (slide 5), depending, again, on the options and features that you select. The speech recognition feature requires a minimum of a Pentium II 400 MHz processor. InfoPath 2003 requires Internet Explorer 6 or later. Just Office 2003 has a minimum requirement of Internet Explorer 5.1. So please remember that if you also want to include InfoPath in your installation, you need to upgrade to Internet Explorer 6.

Office Access 2003 requires the Jet 4.0 Service Pack 7 update, and this includes an updated sandbox mode that allows Access to block potentially unsafe expressions. Some of the features in Access 2003 will not function correctly if you don't install Jet 4.0 Service Pack 7.

Last, Visio® Standard 2003 and Office Professional Visio 2003 require Internet Explorer 5.5 or later.

This brings us to the beginning of the Office 2003 setup sequence (slide 6). When we begin the Office 2003 setup, Setup.exe will read the Setup.ini files to determine the appropriate command line to assemble for the Windows Installer. In addition, it also runs some checks and balances on the system. It will check for the minimum requirements of the operating system to ensure that we're at the minimum OS of Windows 2000 Service Pack 3 or Windows XP.

Then it also checks the .msi file to determine if we're running from a CD or a compressed source versus an administrative installation. If it determines that we're installing from the CD or a compressed source, a flat copy of the CD essentially, then the Office Source Engine is installed. The Office Source Engine will install itself to the drive with the most space. It will create an MSOCache download code directory.

It then creates a single cabinet file to the local computer and extracts the files in a hidden folder. The initial .cab file includes the .msi file. So the Office package, files to support upgrades from previous versions, files like Offcln.exe, Oclncore.opc, which defines what will be upgraded or removed from the previous installation, and Oclncust.opc and Oclnintl.opc.

It also installs error reporting tools, the Dw.exe and Dwintl.dll, as well as Setup Help. After it goes through that process, the Office Source Engine will also check to determine if we have enough disk space to also create the Local Installation Source. If it does, then at that time it will finish copying the entire compressed source down to the local hard drive.

At that point, Setup.exe then calls the Windows Installer Msiexec.exe to launch the installation of Office. It uses the command line, something like msiexec /i; then it calls the display settings that are normally defined in the Setup.ini, logging settings that are also gathered from the Setup.ini, and any other options that are specified. And then it calls the actual Office package file, the .msi file.

There are distinct advantages to the Local Installation Source (slide 7). We had requests from many of our customers for this, because of remote users or laptop users who don't always have connectivity to the network. As I just described, it does require Setup.exe, and it does require that the installation is being run from a CD or a compressed, flat copy of the CD. If we're running from an Administrative Installation Point, the option for the Local Installation Source is no longer available.

It is created by default by Setup.exe. It does use the Office Source Engine. It caches the compressed cabinet files on the local box, and then the Windows Installer is redirected to use that cached source as the installation source. So when Msiexec starts, it actually runs from that MSOCache Local Installation Source rather than from the original CD. So at that point the Local Installation Source does become the true source for resiliency and for maintenance of the installation on that PC.

If you choose to still create and use an Administrative Installation Point, or an AIP, we use the same method that we used with Microsoft Office XP and Office 2000 (slide 8). You run Setup using /a. So we can run setup.exe /a and point to the source for our installation. Or we can run msi.exe /a, and point to the source for our installation.

An Administrative Installation Point creates ease of deployment if you're using Group Policies or System Management Server to deploy Office 2003. It does have an advantage in that you've got a single point of update where you just simply apply administrative patches to the Administrative Installation Point, and then re-cache your clients to that Administrative Installation Point to provide the updates to them.

An Administrative Installation Point — because it is not a true installation, it is simply a source; it's just an expanded source — can be copied from one location to another one to allow multiple sources of resiliency.

As I just mentioned, it does require client synchronization for updates. It also requires, if you believe that in the future you may need to use a CD copy of the source for resiliency, that you use MSINODISABLEMEDIA property during the creation of the Administrative Installation Point. That will allow Office 2003 to switch between a compressed source versus a non-compressed source, for resiliency. This sets the DISABLEMEDIA property actually within the MSI file itself, which is being cached down on the client. You've got an example of a command line there, how you would use that. The command line is setup.exe /a /MSINODISABLEMEDIA=1.

This brings us to customizing Office 2003 (slide 9). We can customize even if we're using a compressed CD image. Again, we have no requirement for the /a setup switch. The files remain compressed so they take up less space. However, to use this as an installation source for our clients, it does require us to provide the Product Key during the installation process, and we would recommend that you also accept the End User License Agreement for the user during this installation process.

The way that we would accomplish this is through the Custom Installation Wizard, and it has a specific page that will allow us to enter the Product ID or Product Key, and to select to accept the End User License Agreement. We need to remember that we need additional disk space for the Local Installation Source. And we have some command-line properties for setting the Local Installation Source.

One of the properties is the LOCALCACHEDRIVE, where we can specify the drive that we want that list to go to, rather than letting Office decide for itself and choosing the largest available drive. We can set it to be a deleteable cache. We don't recommend that, but we can do that with a property DELETEABLECACHE. We can use the CDCACHE command line, meaning that we want to keep the cache on the actual CD.

(Slide 10) It is very similar to customizing an Administrative Installation Point, with the exception of those two options that I just described: we need to provide the Product Key, as well as accept the End User License Agreement. We can also customize the Setup.ini, just like we can with any Office installation. As I mentioned, we configure the option in the Custom Installation Wizard. So there is actually an option in the Custom Installation Wizard to create a Local Installation Source or not to create the Local Installation Source.

We have several methods for customization (slide 11). We have the Setup.ini. So we can customize the Setup.ini, which is read by Setup.exe. We can specify display settings. So do we want the installation to occur in a fully silent manner? Do we want it to be basic or with a user interface that shows the installation progress, but that does not display any error messages or does not require any interaction with the user? Or do we want full, which requires full interaction of the user? Normally, with most of our enterprise deployments, we do not want that option, but it is available.

We can also set logging. By default, Office 2003 does create a verbose log. However, if any of you have ever called into support, you know that we generally ask for a really verbose log, as we would call it. So there are options within the Setup.ini that you can change to create a fully verbose log for troubleshooting.

You can also use the Setup.ini to chain other Windows Installer-based installations.

One thing to remember about the setup process is that because we require Windows 2000 or later, we can ignore the reboots required when we have a file in use during the installation process. In the past, typically we still required the reboot. Now we can use the REBOOT=Suppress property without any adverse effects.

One thing to remember along that line, though, is if we are chaining installations, the Office 2003 setup process and the Windows Installer do not respect the REBOOT=Suppress for the chained installation. So if one of those installations requests a reboot, the reboot will happen. So that's just something to keep in mind when you're planning your deployment.

We have the option of command-line properties, very much the same properties that we can specify in Setup.ini. It's more an order of preference or what is easier for you to use. So, for example, I can use Setup.exe TRANSFORMS=, specify my custom .mst that I created with my Custom Installation Wizard and all of my special settings that I have, (space) /l *v (for example, Setup.exe TRANSFORMS=<PathToMST>\<MSTName>.mst /l*v %temp%\OffPro2k3.txt) for my verbose logging, space, and then give the path to where I want that log to be written and the name I want the log to be written to. I can do the same thing within the Setup.ini. Anything that I specify, though, on the command line, will take precedence over what was specified in the Setup.ini.

Command-line properties are more useful when we don't have as many customizations to specify, and as I mentioned, when we need to specify a special customization file, the special .mst, a customized Setup.ini, or a settings file.

Then we have our most flexible method for customizing Office, and that is with the Custom Installation Wizard, which creates a transform, otherwise known as an .mst. It has several options. It lets me configure my feature state; do I want Access to be installed, or do I want it to be not available? I can configure certain features to even be not available, hidden, and locked, and that prevents the user from ever being able to install those features.

I can then come behind and use the Custom Maintenance Wizard to install those features, but that gives me explicit control over that. In the Custom Installation Wizard, we can also specify user preferences. In the past, with Office 2000, all we had was the Office Profile Wizard. And we would install Office on a box and configure the applications the way that we wanted them. For example, I wanted Word to save files in Office 97 format, I wanted a special location for my user templates, and have different user preferences like that.

Then I would capture those settings with the Office Profile Wizard, creating an OPS file, and install that OPS file on the system after performing the Office 2000 installation. With Office XP, and now also with Office 2003, the Custom Installation Wizard provides that interface for us to manipulate the user preferences within the transform itself. It's a much cleaner method. It's a method that we recommend.

There are a few settings that are not available in the Custom Installation Wizard, but whenever possible, we recommend that you use that interface. Do remember these are not policies. They are strictly user preferences, so they will set the preferences only for the first use or the installation of Office. But the user can change that permanently at any time. A policy will always reset that preference or setting each time the user launches the application.

We do still have Office Profile Wizard. As I mentioned, it has its uses. There are certain preferences that are still not available in the Custom Installation Wizard. It's difficult to tell you, at this point in time, exactly which preferences those are, but we do identify them on occasion. The .ini can be modified to capture even additional settings that are not already specified in the .ini.

Then we have the Office Removal Wizard, which, by default, will detect and remove previous installations of Office in what's called a safe mode, so that it's very careful. It's configured to very carefully remove components of previous installations of Office, leaving shared components in place. We always leave user preferences and user settings, any user documents in place. Those are never removed. That's considered user data, and it is protected. But that Office Removal Wizard can be customized as well to perform a more complete uninstallation when needed. It can also be run separately.

Here I outlined for you what the order of precedence is for the Windows Installer (slide 12). So that if I specify a property on the command line, in the Setup.ini, or in a transform, this is how the precedence will be taken. The command line always has the highest precedence. We can only use public properties, though, on a command line. There are some private properties as well, that we can set in the transform or the custom .mst.

I have a link for you. We'll go over that later in the broadcast. It references what properties you can specify in the transform. It's on the Windows Installer SDK on MSDN®.

Then, last but not least, the properties specified in the Setup.ini. So if I had properties in the Setup.ini that are not specified in the transform and are not specified on the command line, those properties will still be honored and used.

Something else, though, to remember, if you're not aware of it: Setup.ini is only read by Setup.exe. So if I'm running my setup process or my installation using Msiexec.exe, the Setup.ini will never be read. So that would also include if I'm using group policies to deploy Office, because a Group Policy calls Msiexec. It does not call Setup.exe.

Now one thing that you cannot manipulate, although it is a public property, is the COMPANYNAME property. That property is actually preset automatically by information that's gathered from the registry. If we want to control that setting, then we actually have to use the NOCOMPANYNAME property to specify for the Office setup process to ignore the registry information.

When we use the custom transform or use the Custom Installation Wizard to modify our Office installation (slide 13), we need to remember that that transform can only be used during the initial installation. Many times we take calls where our customers want to modify the installation from what was originally installed, and they are attempting to use a transform. Understandably, that is confusing, because it is a configuration file. Instead, we have to use the Custom Maintenance Wizard when we want to modify an existing installation of Office.

So that's just one thing to remember, that the custom transform is used in the initial installation only. It is cached on the client box, and it is reloaded during each maintenance mode process. It's loaded up into memory. Those settings are read, and that is to, again, provide administrators the granularity and the control over the installation that they need.

As I mentioned before, it's most useful when we have extensive customizations. This is typically used to control the application feature states and the user preferences, although we do also have the options to add files, to add or remove registry entries, and we can even add or run additional programs, with additional options to run those programs once for each user, only during the installation, or also during each maintenance mode process.

It is created using the Custom Installation Wizard. And it is the only method for customization of setup when we're using Group Policy software deployment. So, again, that's just something to remember if you're considering or you're already using Group Policy software deployment for your Office installations. There is no option for command-line switches or properties. We simply build the package off of the .msi file, and then if we need to customize that package, we need to create a custom transform and add that to the software deployment package.

The Office Profile Wizard (slide 14), again, provides for automated capture and distribution of user-defined settings. It is most useful when we have settings that we cannot specify using a custom transform, or if for some reason a custom transform was simply not used, or is not going to be used during the installation process. Then the Office Profile Wizard is a very viable option for presetting user preferences on a box.

It does use the Opw11adm.ini. That .ini is customizable. It has exclude sections, as well as include sections. We capture directories. They are all user preferences, so all those options would reside within the HKEY_CURRENT_USER registry hive and the Ntuser.dat file. Those settings cannot be enforced. They are not policy settings. We do not capture policy settings with the Office Profile Wizard.

The order of precedence needs to be considered. You can add an OPS in a transform file. That will take the highest order of preference, because it is applied after the user settings that I may specify in the transform itself. It will also take precedence over any registry values that I may have added. If I run Proflwiz.exe during setup, that will override anything that was added in the transform itself. So if I add my OPS in the transform, or user settings in the transform, and I call Proflwiz.exe as an added program in the transform, that will take precedence.

Migrated user settings will take precedence only for the installing user, so that is something else to keep in mind. If I have a multiple user system and I have an OPS file that I am using, the second user to log on to the box, when they launch their Office application for the first time, the user settings are first migrated, and then the OPS file is applied. So we may overlay some of the user settings that we wanted to migrate. Now there are ways to prevent that, again, by modifying that Opw11adm.ini file, but we need to be very careful and test very thoroughly. Then, of course, application policies are always going to take precedence over any user preference.

We have the Office Cleanup Wizard (slide 15). It is the Removal Wizard, Offcln.exe. By default it uses the Oclncore.opc file. As I mentioned before, that file is customizable. The core components of the Office Removal Wizard are Offcln.exe, the Oclnintl.opc, the Oclncore.opc, and the Oclncust.opc. The removal wizard is also included as a separate utility, so that can be run separately at any time, if needed.

It does provide a nice user interface if, say, a Help desk just wants to walk a user through running that utility to remove temporary files or unneeded application files. Again, it will automatically run by default in what would be considered a safe mode. It also will list what it's going to remove to allow the user or the administrator, whoever is running the utility, to select the features that will be removed. In addition, it can be run to just simply create a log file to display what would be removed if the utility was run in full mode. So it can be quite handy.

So let's review, again, the methods we have for installing Office 2003 (slide 16). We can run setup from an installation image. That's a CD or an Administrative Installation Point. We can use hard disk imaging. That would be where I install my operating system. I install Office. I install any other applications that are necessary for my business. And I create an actual image or picture of that system for distribution onto other PCs.

That is a perfectly acceptable option. There are generally not many problems. The time when we see the most issues is when we have additional applications that may manipulate the registry or some shared components. Those apps just happen to not be tested together with Office 2003 in, say, a production environment. It may not have been tested well enough, or you weren't capable of testing, so we have to tweak the image a little bit to get that working.

We have the remote installation services, which is the Windows 2000 and Windows 2003 version, if you will, of — I would consider it an unattended installation. It is a form of an image. But it's performed remotely over the network as a PC is brought online, into the domain. You have SMS or other third-party software distribution utilities. The only reminder on the third-party distribution utilities is that we cannot support repackaging of Office into another .msi.

The best story for using the third-party distribution is to still use the CD or the Administrative Installation Point as the source, and call our command line using that third-party distribution.

We have the Group Policy software deployment, and then you have the option to install per-machine, which is recommended, or per-user. The property to install per-machine is ALLUSERS=1. The default property called by Office is ALLUSERS=2, which basically tells it "I prefer to install per-machine" or "I prefer to install using ALLUSERS=1. But if for some reason I'm unable to do that, then install in a per-user mode." So there are times where that ALLUSERS=2 can prevent the halt of an installation, but that may not always be desired. If you know that you want a per-machine installation, we would probably want to specify ALLUSERS=1 to force that error or that stop of the installation, so that we can determine what the problem was.

Then the per-user installation actually uses an ALLUSERS="" or a null value. The issues that we see with the per-user installations — and there are certainly times when that is necessary and valuable — a good example is for Access. There are only so many licenses of Access to be installed in the organization. Perhaps you have multi-user machines. Some of those users need rights to use Access and others do not. That would be a good time to use the per-user installation.

However, it does create more difficulty in maintaining Office and performing updates. Again, that is just something to keep in mind, especially with Group Policy deployments.

This brings us to the multilingual deployment strategies (slide 17). Things to think about include the structure of your organization. What are your system locale requirements? Do you want to allow the MultiLanguage Pack installation to auto-detect the language, or do you want to preset the language on the box? We need to ensure that we match feature states between the original Office 2003 installation and the MultiLanguage Pack installation. Many of the same features reside in both.

So, for example, I have proofing tools within my U.S. English Office 2003 installation. I also have proofing tools within my MultiLanguage Pack installation. If I have proofing tools in the U.S. English Office set to install on first use, I need to ensure that I also have them set to install on first use or to match that feature state in my MultiLanguage Pack installation. We see some anomalies when the feature states do not match, and sometimes it takes us a little while to thread through all of that information and realize and identify that's where the problem actually is.

The registry information that defines the multilingual features is under HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\LanguageResources. We also have an InstallLanguage value, and this is the language that's used for the initial Normal.dot that's created for Word. We have the user interface language, UILanguage. Those are the main two keys and values.

We also want to consider whether or not we want to use localized versions of Office 2003 (slide 18). We do have localized versions available. The localized versions are compatible with the multi-user interface or the MultiLanguage Packs of Office. So in other words, if I have a localized version of Office that I'm using in one branch of my organization and they create Word documents — let's use French, for example — then I have users in another Office that have English Office, but they have the French MultiLanguage Pack. Those documents are interchangeable and are understood and readable by both installations of Office. We do need to make sure that the operating system user locale is set to match the language that we want to use before we install the localized version of Office 2003.

The MultiLanguage Packs can be customized just like any Office installation. It does have an .msi file, so I can load that .msi file using the Custom Installation Wizard, modify my feature states, modify my user preferences, and do whatever I need to do to customize that installation.

I can do the same, as far as I can install from the compressed source and get my Local Installation Source for my resiliency. I can install from an Administrative Installation Point. I can also create combined Administrative Installation Points, because we had many of the components that are shared and are not language-specific. That can lessen the amount of space taken up on my server. It's not always a concern these days, but you never know.

This brings us to Office 2003 security (slide 20). One thing is we have many corporations that are concerned about security. One of those being that we have our new Watsondw.exe that comes with the operating system, our new error reporting, which will attempt to gather information when we have any crashes and report it directly to Microsoft, if you choose to allow that.

Because of security concerns and concerns about allowing organizational information to go outside of that organization, Microsoft also offers the Corporate Error Reporting tool. It's at version 2.0. I believe I've provided a link for it later on. If I have not, I'll have to look that up for you as we finish. There is a link to where it can be downloaded. At some point it will only be available through Software Assurance and some enterprise agreements and Volume License Agreements, just depending on how that agreement is set up.

Follow-up information: The public Web site for general CER information and support tools can be found at http://www.microsoft.com/resources/satech/cer/.

But currently, it is available for anyone to download. What the Corporate Error Reporting does is it allows you to set up an error reporting server within your organization, so that if you have any application crashes, those crashes and all other gathered information is actually reported to the server within your organization.

It creates logs. You, as an administrator, can monitor those crashes and that information, down to the granularity of the machine name and the user name for where the crash occurred. Then, if you so choose, there are two things that you can do. Well, there are more than two things, but two things in particular.

You can report just the error to Microsoft, so that none of your internal information that was gathered, crash logs, .cab files, sometimes we ask for additional files if we feel that would be beneficial for this particular type of crash, but none of that information is sent to Microsoft, just simply the error itself. We can report that, and if there is a fix for that error known to Microsoft, then Microsoft will report that back to you through your Corporate Error Reporting server. You can then propagate those fixes out to your clients that experienced that crash.

Now the other thing that you can do is — well, actually there are three things. So if you call into product support and you're having multiple crashes, then you can provide that information to product support, and we can use that information to either escalate your case or identify a fix. The third option is that you, at your leisure, choose the information that you wish to provide to Microsoft, and report that, just as if the user had allowed it to report on their own.

Something else to consider is that it is always good to enforce macro security levels. Of course, the recommendation is high security. We know that's not always feasible within an organization, because of custom applications that are written, and they require a lower macro security. However, that's just something to remain aware of.

We always want to be conscious of deploying any of the security-related updates provided by Office and to deploy those as soon as possible, because generally those security-related updates are a prevention. We're not coming behind an issue that has already been identified. We've identified a potential risk, and so we're providing an update to prevent that. We also want to avoid disabling Microsoft Visual Basic® for Applications rather than implementing the more secure updates.

The reason for that is that we know many of our Office applications rely heavily on Microsoft Visual Basic for Applications for different pieces of functionality. Again, Access is one of the biggest hitters on that.

We want to thoroughly test before deployment to identify any issues that may arise in your environment, and that would include if we want to lock down our boxes, lock down the registry, lock down directories. Let's thoroughly test that to ensure that we're not losing any functionality for our restricted users, that might come back and bite us later.

Determine your corporate strategy and enforce it.

Then also you can consider implementing security-related policies, and those would include application policies. Office also honors many, if not all, of the operating system security-related policies.

Now we're down to troubleshooting (slide 21). We all love that, but it is helpful to have. Of course, again, I cannot say enough about verbose logging, that the really verbose logging is really helpful. It will be requested any time you call into product support for help.

We can enable that in several ways. One is by going into the MMC, loading up the local Group Policy (or we can do it with the domain policy), and under Windows Components there is a Windows Installer policy tree. Within that is Logging Policy. In Logging Policy we would enable it and select All Options. Those options come out to an acronym of VOICE WARMUP. They are specified for you in the actual policy, so you can see what each one of those options does.

The "V" is verbose. The "Properties" gives us a property dump, all of the custom actions. We need that information to accurately identify what happened during the installation process, particularly if we had a problem. We can also just implement the policy through the registry. So we can open up the registry and go into HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer "Logging"="voicewarmup". We can enable the verbose logging there.

What I would recommend doing, and what we do here, is that we create that registry key once, even create it using the MMC, and then just export that key if we want to propagate it to other boxes. Then, also, you can use the command line during the setup process or during the maintenance mode process, and that is with the /l*v switch.

The application event logs are also very helpful now. Windows Installer 2.0 has improved greatly on giving details on problems that were experienced either during the launch of an application or at times during the installation. Typically the event logging is going to give us more when we have problems during an actual launch or during the actual use of an application. Any time the Windows Installer is activated, it will be logged in the event log.

We look, typically, for errors such as 1004s, which tell us that some sort of repair was attempted, but failed. It will give us a component ID that we can look up to identify exactly where we're failing and what we needed. Also, a lot of times it will give you an actual registry key.

We need to confirm what permissions are on the box. Again, I know many of us need to lock our environments down. We're all concerned about security, so we just need to ensure that we're careful in how tightly we lock the system down. For example, many times the System account itself is removed from having permission to certain registry keys or directories. For the Windows Installer and for Office 2003 we leverage the System account for most of our processes. And it absolutely needs full control over the pieces of the Office registry and the directory structure.

Consider that if you have policies — again, we know that after I've installed Office, a restricted user is automatically elevated for any type of maintenance mode process. That does not include patching, but just normal maintenance mode repair processes. The user is automatically elevated. If they don't have the Local Installation Source available, they may not be able to get out to the source to perform a repair if the ALLOWLOCKDOWNBROWSE policy is not set to enable that user to browse out to the network, or if they need to get to a CD, the ALLOWLOCKDOWNMEDIA policy.

We've also found, especially with Windows XP and Windows Server 2003, that there is a "Restrict CD-ROM access" policy that actually is a little bit misleading in the wording. It is an operating system policy, and it defines to restrict CD-ROM access to the currently logged-on user. Well, again, because the system account also needs access during these maintenance mode processes, when we have that restrict CD-ROM access policy in place, the repair process will fail.

That brings us to the additional resources (slide 22). I've listed several Web sites that I believe will be helpful to you as you plan your deployment for Office 2003; Internet Explorer updates, the links to where you can get Internet Explorer fixes or any related updates to your current version of Internet Explorer; information on the local cache options or the Local Installation Source; information on the Windows Installer command-line options; and information on software deployment Group Policy or a reference for the software deployment Group Policy.

There's a white paper on using Systems Management Server (SMS) to deploy Office (slide 23); our recommendations for the method to create a hard disk imagine to include Office; Office 2003 international information; and below that, all of the locale identifiers or LCIDs that belong to each language. Many times those are needed when we're presetting the language either through the registry or through the language settings tool that Office provides. There's how to mitigate potential security threats; and understanding the built-in Office security features;

There's a little more information on policies and how they work (slide 24); information on the Windows Installer logging and those switches that I referenced, the VOICE WARMUP, what each one of those switches means; and information on the event logging and how to interpret that.

That concludes this WebCast for us today and brings us to our question-and-answer session.

Otto: Thank you very much for the presentation. Before we jump into the Q&A section, I'd like to share a couple of quick program notes with our listeners. If any of the details on the PowerPoint® slides were difficult to view in your browser today, or you'd like to simply have a copy of the slides for your reference, or the additional resources, they will be available for download within 24 hours.

The on-demand streaming media will also be available right around the same time frame. That's going to be available on support.microsoft.com/webcasts/ (then click Past Support WebCasts). Simply click today's session, and you should be able to find that information.

The Q&A portion of the Support WebCast is intended to encourage further discussion of the topic that we addressed today. In addition, one-on-one product support issues are outside the scope of what we are able to address. So if you do find that you need some more complex technical assistance, feel free to contact a support professional either by phone or on the Web.

So let's jump into the first question here: Can I upgrade to Outlook® 2003 and then upgrade to the rest of the suite later?

Barbara: Yes. That is no problem at all. The one thing to remember, though, when we do that, is that there are some compatibility issues if you use Word as your e-mail editor, when we have an earlier version of Word than we have of Outlook. So, in other words, I have Outlook 2003, but I have Word 2002. There may be some problems or compatibility issues using those two together. So if you install Outlook 2003 in the environment first, you may choose to simply turn off Word as the e-mail editor until you're able to upgrade to the rest of the suite.

Otto: We have several lab computers around campus, and we'd like the Office install to act as how it is deployed in a Terminal Server environment. Then the second part of the question is: We'd like to get rid of the dialog that prompts for the name and initials when first launching Office products. We're currently using Office 2000, and we've removed the message that is sent to the Inbox the first time we launch Outlook. We're wondering how we do that with the 2003 version. That was the second part of the question.

Barbara: Okay. So I'm hearing they first want Office to act as if it was installed in a Terminal Server configuration.

Otto: That's what it sounds like. Yes.

Barbara: I'm not sure that I fully — I guess they have it installed on each of those lab computers.

Otto: Yes. Perhaps we can ask that user to maybe give us a little bit more detail on what they're looking for, as far as the Terminal Server question is concerned.

Barbara: Yes. I need more detail on that one.

Otto: How about the second part?

Barbara: So, let's see, the second part was, I think I heard two things. One was not getting prompted for the user name initials.

Otto: Right, and then also how to remove that first "Welcome to Outlook" message when you first install Outlook 2003.

Barbara: Removing the user name and initials is simply identifying — there is a UserInfo or UserData key that's written on first launch of the application (HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\UserData or HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Common\UserInfo). There are a couple of things. Depending on if it's a new box — I'm hearing upgrades, so they already have existing user profiles. If it's a new installation or a new user with no existing profile, then the easiest method is to launch the applications one time, and then copy.

That will create a clean local administrator user profile: Launch each application once, and remove the Outlook Windows messaging profile key that's created, because that is unique to each user. So when that's created with the launch of Outlook, then remove that key. And you copy that user profile, the local administrator user profile, to the default user profile. That will pre-populate all the user name and initial information. They can go in and modify it later, if they wish to. If you want it to pick up the actual per-user information, then we really need to allow that process to happen on first launch.

And as far as removing that welcome message, the process should be the same as it was with Outlook 2000 or Outlook 2002. I believe that configuration happens on the Exchange server. I'm a little fuzzy on that, because it's been a while since I've done Exchange support. But that could be something if we need to follow up and provide an answer on, we can.

Otto: Is it possible to use the compressed CD image for LIS and instill update through Group Policy in SMS?

Barbara: Yes. Well, let's think about this. We're saying via Group Policy, but we're using SMS. It's really two separate things. We either use Group Policy or we use SMS. If we're talking about the software deployment, they're both deployment vehicles that provide installations or updates.

So, yes, we can have the Local Installation Source as long as we're using client updates. To perform client updates via Group Policy, it would take a little bit of manipulation, in that there would have to be a package created to drop the client patch or update onto the user's box and then execute a command line or a batch file to launch that update.

That would be the only way for Group Policy software deployment, because otherwise it relies strictly on an Administrative Installation Point and you'd perform a redeploy, via software deployment, to get the updates back down to the client. So Group Policy, I'd say, is kind of questionable and probably not the most recommended way. SMS would be very easy. You just take the patch, push it to the client, and run it. So, yes, with the Local Installation Source, that's entirely possible.

Otto: My organization is assessing deployment of a large number of desktops, 4,600 actually, through Novell Application Launcher or via CD installer at the desktop. Do you have any advice or information on maybe like the pros and cons of each method there?

Barbara: Really it depends on what works best for your organization's needs, taking into consideration network bandwidth. Of course, the CD installation, which would be fully local, is not going to take up any network bandwidth. The Network Application Launcher will require communication across the network.

It depends on — again, I'm not fully familiar with the Novell application launcher, other than what I remember seeing of it. Actually, it's an icon on the desktop that I believe usually requires the user to click it to install. So if that can be staged, then network bandwidth may not be as much of a problem.

I believe the Application Launcher works very well. It works best if you simply call the command line again, either calling Setup.exe or Msiexec, and point to the source for the Office 2003 installation, and let the installation happen that way. I believe the Application Launcher also allows some repackaging, and we have had some problems with that in the past, although I believe Novell has improved their interaction with the Windows Installer. It's really not Office so much as the Windows Installer.

You have to be careful. It can only run one instance of the installer at one time, and sometimes we end up with two. I hope I didn't dance around that one. If that wasn't clear, they can provide some more information to me. I'll be glad to try to address that.

Otto: How do you disable the reading pane during the install?

Barbara: If we can do it, it's going to be with the Custom Installation Wizard in the User Preferences section, because even though it is an Outlook option, that would not be something held in the Windows Messaging profile, I do not believe. That's one thing we always have to keep in mind, is that Outlook has two places that it actually holds the user configuration and preferences.

One is the messaging profile itself that's in a separate registry key. And then user preferences that are underneath the Office key. I don't see it right away, but if we're able to it would be under Change Office User Settings in the Custom Installation Wizard. So I apologize, but I'm not sure if we can do that.

Otto: Do you know if you can disable the Language Bar during installation?

Barbara: The language bar, no. You cannot disable it during installation. The only thing you can do to prevent the Language Bar from coming up would be to exclude alternative user input under Office Shared Features, as well as some additional proofing tools for translation services, and then text services underneath Excel, Text-to-Speech. That's actually what runs those language settings. Ctfmon.exe is the process. And any one of those features that require that, the Language Bar would be enabled by default.

Now it may be possible via policy, but I don't have that in front of me right now, either. If we have time to wait, I can certainly load it up real quick.

Otto: We can always follow up with that offline as well.

Barbara: Okay. Why don't we do that? I'll look into that one.

Otto: Can a custom .mst file later be modified in a Group Policy-based install by modifying the .mst and then redeploying?

Barbara: No. That is not supported. If it's ever attempted, then there are just all kinds of anomalies and undesired behavior that may occur. There are strict naming conventions at the location of the transform itself, because with Office 2003, it's automatically created as what's called a secure transform, so it has to match from the original installation source to the client. Without product support help, that is not a supported configuration.

So to modify it, if there were a need to modify something like that, there are two options. We can uninstall Office and reinstall with the new transform. Of course, that's the most drastic.

There is a tool called Msizap that can be used, and it's very similar to an uninstall, except that no Office files are removed. Essentially Msizap simply removes the installation of Office from the Windows Installer's "mind," if you will. It takes out the Windows Installer registry keys and the uninstall key to fool the Windows Installer into thinking Office is no longer there.

At that point, a reinstall could happen using a new transform. But the most recommended method now is to use the custom maintenance wizard. Because that has been improved, it has virtually all of the options that an .mst or the Custom Installation Wizard has. So I can just combine using my Custom Maintenance Wizard to make the modifications I might think I need to make, using the custom transform.

Otto: When using hard disk imaging, is the SID, or mirroring to the piece of hardware issue, the same as for Office XP, so that we actually have to be sure not to open Office on image?

Barbara: No. That's no longer true. As long as we're using an enterprise SKU and a volume license key for Office, that issue has been addressed, so that the licensing file — we're trusting that our enterprise customers are doing the right thing, and so that DPC file is no longer read.

Otto: Regarding GPOs, could we create two GPOs, maybe one to deploy the English version and one to deploy French version in the same OU?

Barbara: Sure. I assume, even though we're in the same OU, that we're not deploying to the same users or machines, and you just simply set the permissions on the GPO to install to the appropriate machines or users.

Otto: Can the localized version of Office be used on a non-localized version of the OS?

Barbara: Which I would take to mean the English version of the OS. And yes, it can.

Otto: How about security updates via SUS?

Barbara: That is coming. Very good question. We are working as hard and fast as we can to incorporate our Office updates in with the Software Update Services that are currently provided by the operating system in SMS. We had hoped to have it available with the release of Office 2003, and unfortunately, because of the interactions that we require with the Windows Installer and various security concerns around that, we've had to delay that availability.

We hope to have it available some time in the spring. And then we hope to work hard and fast after that to actually also incorporate it with Office XP updates.

Otto: This is just kind of a clarification regarding localized versions being used on non-localized OSs. All of our non-U.S. sites have the U.S. English version of Windows 2000 installed with a Windows MultiLanguage pack for their specific language. We just want to verify that they can install their localized language version of Office 2003 if no language pack exists for their language.

Barbara: So if no operating system language pack exists? I want to say yes, but I'll need to confirm that.

Follow-up answer: The file WWSuppt.xls outlines the functionality available with each localized version of Office on the available operating system configurations. This worksheet, along with other international information documents, is available and automatically installed with the Office 2003 Resource Kit (Ork.exe), downloadable from http://www.microsoft.com/office/ork/2003/tools/BoxA21.htm.

Otto: The next question might be better addressed elsewhere, but I'm going to ask it just in case: How does the licensing work when you customize the Office install and exclude Access, or only include Outlook, for instance?

Barbara: My understanding is that is usually addressed with the technical account manager or the sales team, the licensing team. But even though we've excluded other applications and, as you just said, maybe we only installed Outlook, because the Outlook is part of a full suite that has Word, PowerPoint, Excel, FrontPage®, whatever else is in there, the licensing is for that entire suite. Because it could be installed via that SKU at any time. Does that make sense?

Otto: If that user needs further clarification, perhaps the sales team or your technical account manager will be able to help you out.

Barbara: Right. Because I know there are times where there may be exceptions, but that is not something that product support handles.

Otto: Next question here: You mentioned patching the admin install source, and we had been earlier advised that this is no longer recommended. Instead, we were advised to leave the source pristine, and then chain patches in for setup. And then apply the client patch to the user machines. Which method is preferred?

Barbara: That is something, really, that needs to be determined by each organization, what works best in your environment. So from what I'm hearing, the recommendation that was made was probably based on a product support call, and based on the information we gathered in that particular environment, client patching was the best answer.

It, again, just depends on considerations within the environment, like network bandwidth. A full-file client patch requires less network bandwidth versus patching an admin, which is a single point of update, but then I'm required to touch each client box to sync it back up with that admin point. If it's a full patch, such as Office XP Service Pack 2, it requires a good bit of network bandwidth to get that full update down to the client.

And, again, this is based on whether or not there is network connectivity. Many times, if we have clients that don't always have availability to the source, client patching is generally the best answer. But, again, it's something to be determined by each organization and examined to decide how is it best handled within that organization, what works best for you. So there is no right answer. It's just whatever is best.

Otto: Can we keep PhotoDraw® 2.0, which came with Office 2000, when we upgrade to Office 2003?

Barbara: Yes. That has been reviewed, and it will be supported.

Otto: As far as what's supported and what's not supported: Just to clarify, Windows NT 4.0 is not going to be supported for Office 2003? Is that correct?

Barbara: That is correct.

Otto: Do we still need to apply security updates to the admin install point, or can we start using client updates?

Barbara: You can start using client updates. Again, that's on a case-by-case basis, what works best within the organization.

Otto: I used setup.exe /a to create an AIP, and that failed. Then I picked the setuppro.exe /a, and the process worked. Is that a correct way?

Barbara: Yes. It sounds like, without knowing what was available as far as setups, I know we do name them depending on the SKU of Office that's being installed. So if Setup.exe failed, it almost sounds to like that that one didn't even exist on the CD. So, yes, if setuppro.exe /a works, that's the one you use.

Otto: What about parameters for migration of VBA macros or old Office files? Is there any solution or parameter there?

Barbara: No. Not that I know of, at this point. I know we are looking at this. Well, without knowing the exact problem, I know there are times when there are issues with upgrading or migrating macros. It is reviewed. It's a topic in almost every discussion that I attend, for things that we want to try to address, going forward. I can say that we have almost completed a white paper that specifically outlines different migration issues that we know may come up (and this would be one of them) and the solutions that we've identified, or the workarounds, if you will, that may be available for those different issues.

It'll give you the differences, what's available in Office 2003 versus XP or 2000, give you a comparison of those, as well as different migration issues that we're aware of, and that we want to make our customers aware of, so they can plan. We hope to have that white paper available within the next month.

Otto: We may have already addressed this with previous questions, but I'm going to ask it just in case: Are there any issues with upgrading to, say, Word, Excel, and PowerPoint 2003, but staying with Access 2000?

Barbara: No. That would be the same, you're right, as the other question, I think that was regarding Outlook. So, yes, you can upgrade a little bit at a time. That is not a problem.

Otto: There is a possibility to indicate more than one .mst file inside the Setup.ini. What happens here? Are the properties of the first file overwritten?

Barbara: They can be. That's an excellent question as well. Really, the design of specifying multiple transform files is that we have transforms that contain different options or properties, so that one does not conflict with the other. There may be a conflict, or we may have the same settings or same features, let's use that as an example set. For example, in my first transform, I've set a feature to be not available, and then in the second transform I've set it to be installed on first use. It will, in fact, be installed on first use. Because the last transform applied is the one to take precedence. So that is something to keep in mind if we use multiple transforms.

There are different fixes that we've put out in the past where the transform was pretty generic, but it just happened to change a specific property value that was needed for a customer's environment. So it was safe to use in combination with others, because it didn't set any other feature states or properties.

Otto: We have a clarification on admin install points: Do you recommend installing the Office 2003 and Publisher 2003 admin install points in the same directory structure? And should Project, FrontPage, and Visio be in that same directory, or in maybe a separate admin install point directory?

Barbara: Again, it depends on what's easier for you to maintain. They can certainly be combined into the same admin point. It does, again, reduce the size of the total space used by the Administrative Installation Points, because there are many of the same shared components across all of the applications or all of the suites. So you will save space in that respect.

Off the top of my head, I believe we've done very well with 2003 applications, as far as naming. So, in other words, the Visio uses Setup.exe specific to Visio, names specific to Visio. So hopefully it's named "Setupvis.exe" or something to that effect. But that's something to keep in mind. There is information in the Office Resource Kit on creating a combined Administrative Installation Point.

We just have to know that we need unique names for the Setup.exe file that belongs to each application or each suite, along with Autorun.inf and the Setup.ini. All of those have to be named the same. So, for example, with Office 2003 Professional, it's Setuppro.exe, Setuppro.ini, and so on. That way I ensure none of those files are overwritten, and they're all appropriately updated when I patch that Administrative Installation Point.

Otto: We have a clarification question on language packs: We're running an Office 2000 MUI environment with the different language packs installed, and we're wondering, when installing Project 2003 MUI later, what installation procedure is necessary for the language packs?

Barbara: They have Office 2000 with the MUI, and they're going to install Project 2003 with the MUI. The question is: What's the procedure to get that accomplished?

Otto: Yes. For the language packs and such, if there is anything that's necessary to maintain compatibility.

Barbara: No. The Project 2003 MUI is backward compatible and it's fully aware of Office 2000 and its MUIs. So any installation that happens, if there are any shared components, those shared files will be aware of the Office 2000 MUIs and will work appropriately with them. So it's an installation like any other. You just determine if you're going to perform the compressed source install, with the Local Installation Source, or the admin install, and set your feature states to match with Project 2003 and the Project MUI, and just go from there.

Otto: If we want to use compressed local cache source, do we simply copy the .cab files to the designated hidden folder, then run Setup.exe with the associated transform from that location? My question has more to do with delivery of the .cab files from an enterprise software delivery tool.

Barbara: That can be done, but it doesn't create a true Local Installation Source if we manually copy the compressed files or the .cab files down to the box. We really want to allow Office Setup to perform that function for us. It then sets the appropriate registry keys, including the last used source in the registry for the resiliency and to point to the local install source. We have a couple of reasons for that.

Then Setup.exe determines that we can install a Local Installation Source. It installs and runs the Office Source Engine, which then creates the Local Installation Source and the Office Source Engine, then calls Msiexec and points Msiexec to that Local Installation Source to run the actual setup and to run the actual installation. That creates the Local Installation Source as the preferred source for maintenance, repairs, and resiliency, whatever we need.

Now the other piece of that is that if, for some reason, the cached .msi goes missing from the actual install, if for some reason it gets corrupted or gets deleted, and then the Local Installation Source would know to create a new cached .msi for the client on the box.

In addition, if the .msi in the local installation source itself, for some reason, gets corrupted or gets deleted, the Office Source Engine is actually smart enough to then go back to the original installation source, be it the CD or a flat copy of the CD up on the network somewhere, to pull down a new copy of the .msi into the Local Installation Source. So for all of that to mesh together, we need to allow the setup process to do that itself, rather than manually trying to create that. Did that make sense?

Otto: As long as the Jet 4.0 Service Pack 7 is in place, are there any potential compatibility issues in using Access 2002 shared databases with Access 2003?

Barbara: Not that I know of, but I am not an Access specialist. Again, in the resource kit and in this white paper that we're putting together, if there are any issues, that should be noted within that white paper. But from the review that we've had on potential initial installation and compatibility issues, I have not seen anything indicating that we'd have a problem there.

Otto: What about upgrading all the Office apps to Office 2003, except for Access, and staying with Access 97?

Barbara: We have customers who do that, and we know they have good reasons for it. We have worked very hard, though, to improve Access 2003 and its compatibility with previous versions of Access, and to make the migration story much better. So I would recommend at least investigating that. However, yes, to leave Access 97 on the box, again, is not a problem. That will work just fine.

Otto: Are there any tools recommended for identifying macros and files on the network or on the hard drives?

Barbara: Basically an inventory tool?

Otto: Yes. That's what it almost sounds like, the ability to detect macros over the intranet or local to the drive.

Barbara: I do not know. Well, we may be able to query some metadata. I don't know that we actually have a tool written. It's probably possible to write something. That would be something that would either need to be taken offline, or we can open an advisory case and work with our programming group to investigate that.

Otto: With that, it appears that we've answered all the questions that have been submitted to the queue today. So I'm going to wrap up the session. I want to thank you today, Barbara, for coming out and giving us a great presentation. Of course I want to thank you, our listeners, for coming out and tuning in. We hope that all this information was useful to you and your business.

I hope that everyone has the opportunity to tune in again soon. Thank you, and have a great day.