The Log
The script logs the success or failure of the
setup.exe command after the command is
executed on each system. You must create a log
file. The script is coded to work with a Microsoft
Excel worksheet (Excel 97–2003 .xls format) as
the log file, although you can change the script
to work with a log file in the form of a Microsoft
Access database (.mdb), Microsoft SQL Server
database, or Office 2007 format database (.xlsx
or .accdb). If you create an Excel worksheet,
you’ll want to create column labels in the first
row that match the labels defined in the script
(i.e., ComputerName, Action, Status, Date,
Notes). If you rename the worksheet from the
Excel default name, Sheet1, remember that you
must change the sTable variable in the script.
Save the script to a folder to which Authenticated
Users have read, execute, and write
permission, and configure the variable sFile to
point to the database.
The Groups
You can use the log to audit the success and
failure of setup.exe, but it’s also handy to be able
to easily monitor the machines on which Office
should be installed, those for which setup.exe
succeeded, and those that encountered errors.
To do so, leverage Active Directory (AD) as your
database and create the following three global
security groups in AD:
- CCM_Office 2007 Deploy: This group will
contain the computers to which Office 2007
will be deployed.
- APP_Office 2007: This group will contain
computers on which Office 2007 has been
successfully installed.
- ALERT_Office 2007 Deploy: This group will
be used to flag computers on which Office
2007 deployment failed. You can then monitor
this group’s membership to determine
which systems might need support.
The benefit of using AD as a database
is that doing so makes it easy to manage
change using group memberships. Computers
in the CCM_Office 2007 Deploy group (CCM
for Change and Configuration Management)
will run the script using the methods described
below. When the script succeeds, it moves the
computer into the APP_Office 2007 group. If
the script fails, it moves the computer into the
ALERT_Office 2007 Deploy group. With either
success or failure, the computer is removed
from the CCM group, so that the script doesn’t
run repeatedly.
For the script to move the computer between
groups, you must delegate these groups correctly.
These groups require the Self Allow Write
Members permission. With this permission, the
special identity Self must be allowed to modify
the Members property. A user (or computer)
can add or remove itself from a group but can’t
add or remove other members. You can configure
this access control entry (ACE) in the Security
Properties dialog box of each group or place
these groups in an organizational unit (OU)
delegated with the Allow Self Modify Members
ACE.
This ACE can be delegated on the OU.
To do so, open the Microsoft Management
Console (MMC) Active Directory Users and
Computers snap-in and select Advanced Features
from the View menu. Then, right-click
the OU containing the three groups and select
Properties. Now, click Advanced under the
Security tab. Click Add and enter SELF for the
User or Group. Then click OK. In the Permission
Settings dialog box, click the Property tab
and select Group Objects from the drop-down
menu. Now select the Allow check box for the
Members property.
Group Policy Startup Script
Although GPSI doesn’t support Office 2007’s
setup.exe command, startup scripts can execute
any command you want to run. Startup scripts
run locally in the context of the System identity,
which provides sufficient access to run setup
.exe successfully.
The Microsoft article “Use Group Policy to
assign computer startup scripts for 2007 Office
deployment” (technet2.microsoft.com/Office/en-us/library/a57c8446-b959-4025-a866-b690ddcaa66d1033.mspx) describes how to
use startup scripts for Office 2007 deployment.
Although the article is strong on concepts and
on step-by-step instructions for creating and
assigning startup scripts, the actual script it proposes
is weak. Our script is much more robust.
There are two things to keep in mind if you
decide to use startup scripts to deploy software.The first is the length of time it takes to perform
the installation. Startup-script processing times
out after 10 minutes by default, so you’ll need to
match the script timeout Group Policy Object
(GPO) setting located under Computer Configuration Administrative Templates\System Scripts\Maximum wait time for Group Policy
scripts with the maximum time (in seconds)
that’s required to install Office. Determine the
time through testing, but 15 to 20 minutes (900
to 1200 seconds) should be enough. I recommend
configuring the expanded script timeout
in the same GPO that you use to deploy Office,
so that when the GPO no longer applies to a
computer, its script timeout will return to the
default or to another setting configured by other
custom GPOs.
The other thing you must keep in mind
when using startup scripts is how it will impact
your end users. Startup scripts will run at each
system startup, so you don’t want to be running
setup.exe every time a client computer
is booted. Setup won’t reinstall Office—it will
detect the existing installation successfully—
but it will still take time to process. Therefore,
you want to configure your startup script to
verify whether Office 2007 already exists on the
system prior to running setup.exe. If Office 2007
has already been installed, the script will exit
without running setup.exe.
There are several ways to configure your
startup script to verify whether Office is already
on a system. One way is to read the registry
key that displays Office 2007 in the Add/
Remove Programs list. If it’s there, Office
2007 is installed. Another method is to create
your own registry entry to track the successful
installation of Office 2007. I’m a big fan of
tagging systems for CCM. You can also create
a “flag file” on the hard disk. Many systems
administrators use this approach to tag a
system. An empty text file is created with a
specific name such as C:\OfficeDeployed.txt.
A script looks for this file to determine whether
the script should run. I prefer to use a registry
change rather than the flag-file method, since
disk reads are more “expensive” than registry
reads from a processing perspective, and
there’s a risk of the file being deleted from the
disk.
Finally, you can use a security group to
deploy Office 2007. To do so, create a GPO called
Office 2007 Deploy. This GPO will configure the
startup script, which will install Office 2007. Edit
the GPO Startup Script policy settings to run
your script: The Script Name should be cscript
.exe, and the Script Parameters should be the full
path to your script in the Office network installation
point, as Figure 1 shows. Try to avoid using
spaces in the pathname or filename.
After you’ve created the Office 2007 Deploy
GPO with the startup script that installs Office
2007, filter the GPO so that it applies to only
the CCM_Office 2007 Deploy group, as Figure
2 shows. Don’t forget to remove Authenticated
Users from the filter.
Any computer that’s in the CCM_Office
2007 Deploy group will run the startup script
and install Office 2007. Now here comes
the creative part. Because the startup script
includes code that removes the computer
from the group, the startup script will run
only one time on that computer. Also, if Office
installs successfully, the computer will be
moved to the APP_Office 2007 group. You can
use that group to monitor and report which
computers have Office 2007. If Office installation
fails for some reason, the computer will
be added to the ALERT_Office 2007 Deploy
group, which acts as a “red flag” for computers
that should be examined to determine why
Office installation failed.
Wrapping Up
We’ve created a script that acts as a “build-ityourself”
SMS or Systems Center Configuration
Manager by executing an action, logging the
results, and ensuring the action doesn’t happen
again. We’ve also looked at how to deploy
the script by using Group Policy startup scripts.
For more information about other Office 2007
deployment methods, see the Web-exclusive
sidebar “Alternative Office 2007 Deployment
Methods,” InstantDoc ID 97263. The approach
I’ve laid out can be used for several systems
management tasks in addition to deployment of
Office 2007.
End of Article
)
)
)
Register
vcp2522 November 04, 2007 (Article Rating: