How to deploy Office 2007 by using Group Policy to assign startup scripts


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 ConfigurationWindows 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 ConfigurationWindows 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 ConfigurationAdministrative TemplatesSystemScripts 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 .bat 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 .bat 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=\servershareOffice12

 

REM Set ConfigFile to the configuration file to be used for deployment REM (required)

set ConfigFile=\servershareOffice12Enterprise.WWconfig.xml

 

REM Set LogLocation to a central directory to collect log files.

set LogLocation=\servershareOffice12Logs

 

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_MACHINESOFTWARE%WOW6432NODE%MicrosoftWindowsCurrentVersionUninstall%ProductName%

if %errorlevel%==1 (goto DeployOffice) else (goto End)

 

REM If 1 returned, the product was not found. Run set

Comments (3)

  1. Mark says:

    Thanks for this, it was quite handy!

    Small point, the script above will fail to detect a previous successful install of Office 14 because the registry path being queried will never exist.

    I think you need to change the reg query command from  

    reg query HKEY_LOCAL_MACHINESOFTWARE%WOW6432NODE%MicrosoftWindowsCurrentVersionUninstall%ProductName%

    to

    reg query HKEY_LOCAL_MACHINESOFTWARE%WOW6432NODE%MicrosoftWindowsCurrentVersionUninstallOffice14.%ProductName%

  2. Ben says:

    Hi Mark,

    Thanks for the suggestion. Wanted to let you know that the script has actually been updated for Office 2010.  The updated script has the following in the customization section which takes care of this:

    set ProductName=Office14.PROPLUS

    Here is a link to the updated article: technet.microsoft.com/…/ff602181.aspx.