For those of you not familiar with the Office Customization Tool (OCT), it is your main tool for unified setup, customization, and maintenance of the Office 2007 system. It's free and comes with the volume licensed version of the 2007 Office system. It's not in the Office Resource Kit…because the 2007 Office Resource Kit is a document library and not a downloadable set of tools. But you knew that, right?! Right?
If you haven't already, you'll want to download the newest version of the OCT at http://go.microsoft.com/fwlink/?LinkId=102314.
When you save your customizations in the OCT, it produces an .MSP file.
Here are a few quick tips when working with the OCT:
· Put your PID here! The Config.xml file isn't encrypted. If you put your PID there, it'll be stored in clear text. Not a good idea! So use the OCT for PIDs instead.
· Pick one! If you have conflicting settings between the .MSP file you created in OCT and your Config.xml file, the Config.xml file settings will win. If you don't specify something in Config.xml, it'll take the corresponding settings in the OCT. So decide what tool you'll use for what and consistently use those tools for that purpose.
· Keep it quiet! Accept the Microsoft Software License Terms on behalf of your users and suppress the dialogs with Display level =None, especially when doing an enterprise deployment.
· Don't be confused! There are some settings in the OCT that may mystify - e.g., "disable auto republish". Do you select the disable checkbox to enable or the enable checkbox to disable? Think of the checkboxes instead as enable checkbox = true and disable checkbox = false. So if I want auto republish to be disabled, I'm going to select the checkbox that indicates that "disable auto republish" is a true statement (which is the enable checkbox). Additionally, the explain text on some options might not help make you make the right choices - which leads us to the next point.
· Test everything!! Verify all your settings will deploy as expected in a pre-production/test environment before you deploy to your users.
· You wouldn't name your dog "dog"! Name your .MSP files so you can identify them! For example, 1_Ofc-2007-Ent-APAC-v2-initial.msp could tell you that this is an Office Enterprise 2007 patch for the Asia Pacific region at your company, version 2, and for initial installs (the first one used in the Updates folder).
· Be exact! If you have multiple .MSP files, setup will apply the first OCT MSP file in Windows sort order. Then after the install, setup will apply the remaining MSP files based on the Windows Installer patch sequencing rules. So, to get the expected results for new installs where you just want to apply one OCT MSP file, you should use the setup /adminfile command to point to the specific .MSP file you want when deploying. For example: setup.exe /adminfile \\server\share\mychanges\mycustom.msp. Alternatively, if you want to apply multiple OCT MSP files with setup, name the primary OCT MSP file so it'll be loaded first (for example, start the file name with "1_"). Keep in mind that the first MSP file in Windows sort order should have all the major setup information (PID, setup display settings, applications to install, etc.).
· Make it work! If you have an existing installation of the 2007 Office system and you try to add some customizations using the original .MSP file, you may get unexpected results. To make it work for existing installations, create a new .MSP file with just your new customizations. Deploy this new .MSP file via your deployment tool of choice to the existing installations. This could be as simple as having your users double-click the .MSP file manually to have it applied. For new installations, update your existing .MSP file with the new customizations - but keep in mind the next bullet….
· Keep it fresh! MSP files can get corrupted if you update them several times (like 20 to 30 times). Bad news! So best practice is to refine your customizations in a separate pre-production/test .MSP file. Once that's final and ready for prime time, create a new .MSP file to deploy with your final customizations.
· What are my customizations?! Unfortunately, there isn't a super handy way to get a copy, print out, or report of what your customizations are but…there is a script that helps! See the article View XML content from Office Customization Tool customization files (http://technet.microsoft.com/en-us/library/cc179027.aspx). After running the script, you can review the resultant XML by right clicking it in Internet Explorer and choosing the Export to Excel option.
For more information about the OCT, see Office Customization Tool in the 2007 Office system (http://technet.microsoft.com/en-us/library/cc179097.aspx).
– Cat Watson
You can use Group Policy to assign computer startup scripts to deploy the 2007 Microsoft Office system. You can use a script written in any language that is supported by your client computers. Windows Script Host-supported languages, such as VBScript and Jscript, and command files are the most common.
Group Policy Scripts Extensions
The Group Policy infrastructure includes a Scripts extension that consists of:
· A Microsoft Management Console (MMC) server-side extension of the Group Policy Object Editor MMC snap-in that is used for administering and configuring scripts. You can use the scripts extension to specify scripts policy settings in a GPO and then link the GPO to the site, domain, or organizational unit to which you want to assign the scripts.
· A client-side extension, which is a DLL on the client computer that interacts with the Group Policy infrastructure and implements Group Policy scripts on the client computer. A separate process called Userinit.exe runs the scripts.
The GPO Editor snap-in includes two extensions for script deployment:
· Scripts (Startup/Shutdown). Use this extension to specify scripts that run when the computer starts up or shuts down. These scripts run as Local System. Scripts (Startup/Shutdown) is located under the Computer Configuration\Windows Settings node of the GPO Editor.
· Scripts (Logon/Logoff). Use this extension to specify scripts that run when the user logs on or logs off the computer. These scripts run as User, not as Administrator. Scripts (Logon/Logoff) is located under the User Configuration\Windows Settings node of the GPO Editor.
For more information about Group Policy Scripts extensions, see the Scripts Extension Technical Reference. For information about Windows Script Host, see Windows Script Host.
Advantages
If you have already deployed Active Directory and Group Policy in your organization, using computer startup scripts to deploy Office 2007 provides the following benefits:
· Scripts or batch files for Office 2007 client deployment are relatively simple to create.
· Administrators can use a command line to point to their Office Setup customization file (.MSP file) for advanced feature and settings customization. Setup customization files are created when administrators use the Office Customization Tool (OCT) to customize an installation of the 2007 Microsoft Office system. For more information about .MSP files, see Office Customization Tool in the 2007 Office system.
· Administrators can use a command line to point to the Config.xml file for adding languages and other customizations. Modifying the Config.xml file is one of the ways in which administrators can make changes to the 2007 Office system installation. For more information about Config.xml files, see Config.xml file in the 2007 Office system, and the Applying customizations to the Office installation and Modifying the Config.xml File OptionState element sections in Use Group Policy Software Installation to deploy the 2007 Office system.
· The source files for product installation can be stored on a network share or on each local computer, if the bits are pre-staged.
· The product installation occurs in the system context, before the users log on. Active Directory handles the elevation of privileges required for application installation.
· Users can add or remove product features by using Add or Remove Programs in Control Panel.
· Administrators can use a similar scripting process to apply security updates and service packs for each computer in the domain or organizational unit.
· Microsoft Windows Server Update Services 3.0 (WSUS 3.0) can be used to manage and deliver product updates. For information about WSUS, see Microsoft Windows Server Update Services 3.0 Overview and Step-by-Step Guide to Getting Started with Microsoft Windows Server Update Services 3.0 on the Microsoft TechNet Web site.
Considerations
Be sure to consider the following issues:
· The product installation is not managed in the same way as Group Policy Software Installation.
· Group Policy invokes the script and has limited awareness of the installation state thereafter. If the GPO that contains the script is removed (goes out of scope), Office is not removed.
· Deploying with scripts requires basic knowledge of valid command-line options for Setup.exe in 2007 Office applications. For information about command-line options, see Setup command-line options for the 2007 Office system.
· Product uninstalls and reinstalls for multiple computers have to be done by using a command line script or batch file.
· Automatic product reinstall after a user-initiated uninstall does not work in the same way as when Group Policy Software Installation is used. With Group Policy Software Installation, if a user removes a user-assigned application by using Add or Remove Programs in Control Panel, the Group Policy Software installation extension automatically reapplies the advertisement information after the user logs on or the computer restarts. The software is reinstalled the next time the user selects it or tries to open a file with an associated file name extension.
· Determining exactly which updates and service packs were applied for each client computer may be difficult.
Group Policy provides the ability to affect configurations across hundreds and even thousands of computers in an organization. Therefore, it is critical that you rigorously test all new Group Policy configurations or deployments in a non-production environment before you move them into your production environment. For detailed information about staging Group Policy deployments, see Staging Group Policy Deployments in the Designing a Managed Environment book of the Microsoft Windows Server 2003 Deployment Kit.
By default, the system lets combined sets of scripts run for up to 600 seconds (10 minutes) only. Administrators can use a policy setting to adjust this interval to ensure the startup script completes running. The Maximum wait time for Group Policy scripts policy setting specifies how long the system waits for scripts applied by Group Policy to run. This setting limits the total time allowed for all logon, startup, and shutdown scripts applied by Group Policy to finish running. As with any Group Policy deployment, you must fully test your startup scripts in a staging environment before deploying them to your production environment. Testing will help you determine the value to use for the Maximum wait time for Group Policy scripts policy for your particular network environment. Setting this value too low may cause the install to terminate prematurely. There are factors that may affect this value, such as network speed, client computer hardware, and other scripts running on the client computer. By fully testing this policy setting you can determine the appropriate value to use for your specific environment.
The Maximum wait time for Group Policy scripts policy setting is available in the Computer Configuration\Administrative Templates\System\Scripts folder in Group Policy Object Editor. For information about configuring this policy setting, see Specifying maximum time for startup scripts to run.
Startup scripts
Startup scripts run as Local System and have the full rights required to run as Local System.
If you haven’t already installed GPMC, you can get it at Download Group Policy Management Console (GPMC). For more information and procedures for using GPMC and working with GPOs, see Group Policy Management Tools and Using Group Policy Management Console and Group Policy Object Editor sections in Enforce settings by using Group Policy in the 2007 Office system.
You must be logged on as a member of the Domain Administrators security group, the Enterprise Administrators security group, or the Group Policy Creator Owners security group to complete these procedures.
Sample script
The following sample script illustrates how to perform the following tasks:
· Run Microsoft Office Setup.exe if the product is not already installed.
· Log error or success to a centralized log file.
This script example provides flexibility and can be customized for other Office products. The following requirements apply to the sample script:
· The target computer must be running Windows XP, Windows Server 2003, Windows Vista, or Windows Server 2008.
· Microsoft Windows Installer (MSI) 3.1 is required if you use a customization patch
· A Read-only network share containing the Office source files
· A Read-write network share for storing centralized log files
· A custom Config.xml file or customization patch to direct Setup.exe to run quietly. For instructions for modifying the Display element in the Config.xml file, see Specifying Silent Install Options in Config.xml File, and Display Element in Config.xml file in the 2007 Office system.
REM *********************************************************************
REM Environment customization begins here. Modify variables below.
REM *********************************************************************
REM Get ProductName from the Office product's core Setup.xml file.
set ProductName=Enterprise
REM Set DeployServer to a network-accessible location containing the Office source files.
set DeployServer=\\server\share\Office12
REM Set ConfigFile to the configuration file to be used for deployment REM (required)
set ConfigFile=\\server\share\Office12\Enterprise.WW\config.xml
REM Set LogLocation to a central directory to collect log files.
set LogLocation=\\server\share\Office12Logs
REM *********************************************************************
REM Deployment code begins here. Do not modify anything below this line.
REM *********************************************************************
IF NOT "%ProgramFiles(x86)%"=="" SET WOW6432NODE=WOW6432NODE\
reg query HKEY_LOCAL_MACHINE\SOFTWARE\%WOW6432NODE%Microsoft\Windows\CurrentVersion\Uninstall\%ProductName%
if %errorlevel%==1 (goto DeployOffice) else (goto End)
REM If 1 returned, the product was not found. Run setup here.
:DeployOffice
start /wait %DeployServer%\setup.exe /config %ConfigFile%
echo %date% %time% Setup ended with error code %errorlevel%. >> %LogLocation%\%computername%.txt
REM If 0 or other was returned, the product was found or another error occurred. Do nothing.
:End
Endlocal
In this example, script logging information is written to computername.txt file. A return code of 0 in the log file indicates that the installation completed successfully. A return code of 3010 indicates that a reboot is required. For more information about other error codes for Windows Installer processes for Office products, see KB article 290158 on the Microsoft Knowledge Base Web site.
Specifying Silent Install Options in the Config.xml file
1. Open the Config.xml file in a text editor tool, such as Notepad.
2. Locate the line that contains the Display element, as shown in the following example:
<!-- <Display Level="full" CompletionNotice="yes" SuppressModal="no" AcceptEula="no" /> -->
3. Modify the Display element entry to specify silent install options. For example if you want to specify that no user interface or modal dialog boxes are displayed, use the following syntax:
<Display Level="none" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />
4. Save the Config.xml file in the same folder that contained this file before you edited it.
Setting up scripts on the domain controller
Copy the script and dependent files to the Netlogon shared folder or another shared folder on the domain controller from which you want the script to run.
The target computer account needs Read permission to the Office source files location, and Read and Write permissions to the log file location. The log file can be stored on the local computer.
Assigning computer startup scripts
1. Click Start, click Control Panel, click Administrative Tools, and click Group Policy Management.
2. In the console tree, double-click Group Policy Objects in the forest and domain that contains the Group Policy object (GPO) that you want to edit. This is located in Forest name/Domains/Domain name/Group Policy Objects.
3. Right-click the GPO you want to use to assign scripts and click Edit. This opens the Group Policy Object Editor console.
4. In Group Policy Object Editor, in the console tree, click Scripts (Startup/Shutdown). This is located in the Computer Configuration\Windows Settings node.
5. In the details pane, double-click Startup.
6. In the Startup Properties dialog box, click Add.
7. In the Add a Script dialog box, do the following:
In Script Name, type the path to the script, or click Browse to search for the script file in the Netlogon shared folder on the domain controller.
In Script Parameters, type the parameters you want to use as you would type them on the command line. For example, if your script included parameters called //logo (display banner) and //I (interactive mode), type: //logo //I.
8. In the Startup Properties dialog box, specify the options you want to use. The following options are available:
Startup Scripts for Group Policy object. Lists all the scripts that are currently assigned to the selected Group Policy object. If you assign multiple scripts, the scripts are processed in the order that you specify. To move a script up in the list, select the script and click Up. To move a script down in the list, select the script and click Down.
Add. Opens the Add a Script dialog box, where you can specify additional scripts to use.
Edit. Opens the Edit Script dialog box, where you can modify script information, such as name and parameters.
Remove. Removes the selected script from the Startup Scripts list.
Show Files. Displays the script files that are stored in the selected Group Policy object.
Specifying maximum time for startup scripts to run
Make sure you fully test startup scripts in a staging, non-production environment before you deploy them to your production environment.
1. Click Start, click Control Panel, click Administrative Tools, and click Group Policy Management.
2. In the console tree, double-click Group Policy Objects in the forest and domain that contains the Group Policy object (GPO) that you want to edit. This is located in Forest name/Domains/Domain name/Group Policy Objects.
3. Right-click the GPO you want to use to assign scripts and click Edit. This opens the Group Policy Object Editor console.
4. In Group Policy Object Editor, in the console tree, navigate to Computer Configuration\Administrative Templates\System\Scripts.
5. On the details pane (left side of the console), double-click the Maximum wait time for Group Policy scripts policy setting, click Enabled, enter the value you want to use in the Seconds scroll-down box, and then click OK.
For more information, see the Office Resource Kit downloadable book, Group Policy Overview for Office 2007.