Create More Flexible Office Deployments with the Local Install Source
At a Glance:
- The inner workings of the Local Install Source (LIS)
- Using system environment variables
- Enabling fault-tolerant Office delivery path locations
- Troubleshooting the LIS
Have you ever gotten calls from your traveling employees who need to repair their Microsoft Office 2003 applications, but can't connect to the company network? Wouldn't it be great if
the people you support could have their Office 2003 installation repaired without a VPN connection back to your corporate network? If they received their Office installation from an administrative installation point (AIP), they certainly can't do a repair unless they can access the network resource.
The Local Install Source (LIS), introduced with Office 2003, is an Office Source Engine service feature that eliminates the need to be connected to the corporate network in order to make a repair or change installation options. LIS accomplishes this magic by copying the compressed source files from the Office 2003 installation media (for example, the Office 2003 CD-ROM or a network-based AIP) to the Msocache folder, a hidden folder on your local hard disk that has security permissions applied to it.
In this article I'll cover some important things to know about the inner workings of the LIS and introduce new functionality in the Office Source Engine to ensure that enterprise deployments of Office 2003 with the LIS remain trouble free (especially as server names or mapped drive letters may change.) I will also cover LIS maintenance and finding a valid source. A thorough understanding of the topics in this article will prove highly beneficial for your new or current Office 2003 deployment and future maintenance.
Introducing the LIS
The LIS is different than the administrative installation points you may have used for Office 2000 and Office XP. (Note that you can still technically use, and get support for, an AIP for Office 2003; however, usage of AIPs is expected to be discontinued for the 2007 Microsoft Office system.) One main difference is that LIS source files remain compressed and are stored locally on your hard drive. An AIP, by contrast, contains uncompressed source files that are stored on a network shared resource. Under the AIP system, administrators would frequently run into patch synchronization issues with slipstreaming patches into the AIP, causing them to continually recache client machines to be current with the AIP's patch level.
Also, services such as Microsoft Update, Windows Server Update Services (WSUS), and the Systems Management Server (SMS) Inventory Tool for Microsoft Updates (ITMU) only work with Office XP AIPs that are at an RTM (original media version) level. For Office 2003, the AIP must be at an RTM level or Service Pack 2 (SP2) level. For a better explanation, two Knowledge Base articles describing these issues can help: support.microsoft.com/kb/903773 and support.microsoft.com/kb/902349. For Office XP, see support.microsoft.com/kb/922665.
The primary benefit of the LIS is that you are no longer tied to a network source location if your Office 2003 application needs to perform a self-heal or other resiliency operation. A traveling executive in a hotel room could have her installation of Office 2003 repaired without the need for a VPN connection back to her corporate network. If this executive had received her Office install from an AIP, she would not be able to repair back to a valid source unless she could see that network shared resource from her hotel room.
If you review the Windows® Installer source list location on an Office 2003 installation that uses LIS, you will see that the Installer references a local disk drive location, not a Universal Naming Convention (UNC) or shared network resource like you would see with an AIP. The added benefit of a LIS is that you can repair your Office 2003 applications from the LIS, and the LIS can repair itself as needed.
In the past, with an AIP not only would you have to be connected for a standard Windows Installer application to be repaired, but it could only repair if it was connected to the actual source specified in the installer information for that product. With Office 2003, if the LIS has lost that information, it references the following registry key where the path to the original source used to create the LIS can be found: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Delivery.
What If the Source Is Unavailable?
Of course, all this only works if the original source is still available. Thankfully, the Custom Maintenance Wizard (CMW) utility in the Office 2003 Resource Kit can add extra Office delivery path locations and change the default Office delivery path as well. It's the only supported way to change the Office delivery key after an installation. To accomplish this, see the steps outlined in the Resolution section of the KB article at support.microsoft.com/kb/913420.
To change installer source list locations as needed, SMS provides such features as the Windows Installer (WI) Source Location Manager. In addition, the task of programmatically changing WI source list locations using the WI API is well documented in MSDN® online. However, changing the WI source list location for the LIS (<LocalDriveLetter>:\MSOCACHE) is not supported, so you've always needed another way to change the Office delivery path. Now there's a solution. Using system environment variables, combined with the CMW makes outdated source locations a worry of the past, and you can change the Office delivery locations just as easily as the Windows Installer source list locations. But for the Microsoft Office Source Engine (OSE) to be able to read system environment variables, you'll need the hotfix that is available with the following KB article: support.microsoft.com/kb/915433.
Here's a typical registry key for a static Office delivery path for Office 2003 Professional Enterprise Edition:Here's the same key with a system environment variable:This dynamic variable will certainly make your enterprise deployment and Office software maintenance more flexible. Just remember these two things: this system environment variable must be predefined on all machines first, and at least one reboot is required the first time a system environment variable is created. Afterwards, if the value changes, you do not need to reboot. You should pre-stage your machines by declaring this variable well in advance of your Office deployment. An article explaining environment variables can be found at support.microsoft.com/kb/310519. If you want to automate the setting of a system environment variable after a single reboot, a quick way to do that is to deploy and merge a variable from the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment registry key.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ Delivery\SourceEngine\Downloads\90110409-6000-11D3- 8CFE-0150048383C9\Sources\90110409-6000-11D3-8CFE-0150048383C9. "Path"="R:\\AppServer\\AppShares\\Office2003ProEnt\\"
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ Delivery\SourceEngine\Downloads\90110409-6000-11D3- 8CFE-0150048383C9\Sources\90110409-6000-11D3-8CFE-0150048383C9. "Path"="%SYSTEMVARIABLENAME%\\AppShares\\ Office2003ProEnt\\"
For new deployments of Office 2003, you can specify Office delivery path locations in the original transform, but for existing deployments, you must use the CMW utility. Note that a transform is a Windows Installer Transform (MST) file, which holds various installation settings so you can customize your Office application deployment.
Using the Custom Installation Wizard from the Office 2003 Resource Kit (ORK) toolbox (office.microsoft.com/en-ca/assistance/CH011496861033.aspx), you can specify the locations that will be required when you reach Step 14 of the wizard, as you see in Figure 1. For even greater flexibility, you can specify more than one system variable for your source location.
Figure 1 Specify Office Delivery Path Locations (Click the image for a larger view)
Once Office has been deployed with a transform, you can only use the Custom Maintenance Wizard utility from the ORK Toolbox to revise settings and options that differ from the original transform. Office will only recognize the first and original transform settings unless a CMW file has been deployed.
If you need to add or modify the original Office Delivery source path locations, you can do so in Step 10 of the CMW. Please note that this step only appends locations unless you check the "Clear existing Server list" setting, which you will find in the bottom-left of the screen. In most cases, the sole reason to create this CMW file in the first place is that existing Office Delivery path locations were not valid, so you will almost certainly want to choose to clear the existing server list. As I said earlier, keep in mind that you can have multiple Office Delivery path locations with multiple system variables for extra flexibility.
Now that you have your Office delivery path locations for the LIS properly set, you can focus on maintenance. One important administrative tool is the LISTool, available for download from microsoft.com/office/orkarchive/2003ddl.htm.
With the LISTool, you can move the LIS to a new root drive letter, delete, and enable it. Figure 2 shows LISTool running.
Figure 2 Command-Line Options (Click the image for a larger view)
Figure 3 lists the command-line options you can use with LISTool.exe; you can also view these options by typing /? at the command line. The following Office Resource Kit online link describes the LISTool in more detail: office.microsoft.com/en-us/assistance/ha011402361033.aspx.
In certain troubleshooting scenarios, the best course of action is to delete and re-enable the LIS to ensure its integrity. For example, if you try to start a program such as Microsoft Word, Excel®, or PowerPoint® 2003 for the first time, you may receive the following error message: Installation Error: File not Found (as described here: support.microsoft.com/kb/896866). In this case, you'll need to delete and re-enable the LIS with the LISTool.
Setting Cache Properties
To handle the local installation source separately from the Office 2003 installation, you can set the CACHEONLY property in the [CACHE] section of the Setup.ini file or on the command line. When it is set, CACHEONLY does the following:
- Sets the CDCACHE property to 2.
- Sets the local installation source to NoCleanUp in the Windows registry.
- Directs setup to download all local installation source files and then exit before starting the installation of the Office package.
The final property is ENFORCECACHE, which must be set in the [CACHE] section of the Setup.ini file or on the command line. When it is set, ENFORCECACHE overrides several other properties. See office.microsoft.com/en-us/assistance/ha011402451033.aspx for details.
There are several other ways a LIS can become corrupt or lose files. During certain patching efforts prior to the release of Windows Installer 3.1 v2 there were instances where, during a failed or canceled patch installation, some of the CAB files in the LIS would be erroneously deleted during the rollback operation (see support.microsoft.com/kb/893803). Therefore, it is important that your enterprise also uses the latest version of Windows Installer.
Running the Disk Cleanup Wizard on a drive with more than one partition can be another source of problems. If Disk Cleanup Wizard is run on a partition that does not contain the LIS, the LIS entry for cleanup is still flagged and LIS registry information is erroneously deleted. A hotfix has been created for this issue; see the article at support.microsoft.com/kb/920355.
You can fine-tune some of the LIS initial deployment settings, including pre-staging the LIS by ensuring you are using the latest version of the Enhanced Setup.EXE for Office 2003. Always use the latest available setup.exe, which you can read about and download from office.microsoft.com/en-ca/assistance/HA011402451033.aspx.
The new setup can also deploy the local installation source separately from the Office 2003 installation in case you want the advantages of local caching but need to manage network resources carefully. The local installation source can be deployed first, and Office 2003 can be installed at any time after that. For the steps involved, see the sidebar "Setting Cache Properties." You should now be ready to enjoy more flexible, customizable Office installations.
Dean Yamada is a Product Escalation Lead for the Microsoft Office Setup and Deployment Team (microsoft.com/services/microsoftservices/srv_support.mspx). Dean and his team can answer your Office patching deployment questions or provide an Office deployment workshop onsite. For more information, e-mail him at firstname.lastname@example.org.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.