Question: David wrote: We are planning a deployment of MS Office 2003 at a client site using ZfD401, and would like to know what the current tips and tricks would be to make this a successful rollout. Any pointers would be appreciated.
Answer: OPEN CALL: Got any suggestions for David? Let us know.
Additional Questions (and additional answers)
I used the Office Resource Kit and created a custom MSI. Then I associated the MSI with the user objects I wanted to have the update.
You have to associate the MSI to user objects instead of workstation objects, otherwise the MSI will not install. Set it to run as unsecured and force run it and you are done.
- Do an Admin install of Office 2003 to a share on your server where your ZEN Apps live (:APPS\MSI\Office2003)
(Run set-up /a for Admin install and choose your location on your server)
- Download the Office 2003 Resource Kit.
- Create your MST file using the custom installation wizard with all your relevant settings you want for the App.
- Create a ZENworks MSI app and include the transform file in the App.
(Note:- The additional properties option in the ZEN app will not display anything for Office 2003)
- Apply reporting to your App and roll it out.
Works GREAT, no problems at all.
How to secure the license key and be able to distribute Office.
We wanted to secure the MSI file because if you get a hold of it you can do unlimited installs (provided it is the enterprise version). Do the Admin install of it on a server, and then create a custom install package using the Office Resource Kit. Use rights filters to secure the directory with zero access for users. Then make a trustee assignment giving workstations access to the directory. (MAKE SURE YOU GIVE YOURSELF A TRUSTEE TO THE DIRECTORY) Then set it to run as unsecured system and associate it with workstations only.
The two main issues we found with Office 2003 deployment were:
- Registry issues
- Office product activation lives in a file called opa11.dat and the directory for this is
C:\Documents and Settings\All Users\Application Data\Microsoft\OFFICE\DATA.
This file stores activation for all office products. If you take snapshots of say Word and Excel separately and deploy them, only the application with the most recent opa11.dat will work.
We took the approach of installing the complete suite and activating it just so we had an opa11.dat file that had details for all the products. For each snapshotted app ( word, excel, powerpoint) we simply replaced the captured opa11.dat with the master one.
- Reboot and launch app once. Especially where the user in XP is not an adminstrator, you must reboot even if Office 2003 does not indicate that it needs it. The main reason is that there are changes to HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE that a user less than an adminstrator cannot make.
As Mark Lewis suggested, we too use the Office Resource Kit to create an install point. We used an .MST transform file. The other important thing is the MSI Command line option /qb for quiet install.
We also needed to install other MS components such as MS producer, Frontpage, Jet updates, etc. We did the install via an ?Office install user? which had all the components we wanted associated as forcerun with the final application being a reboot. These were all done with flags to ensure silent installs with no user interaction needed.
All the users see is a single icon that sets up the Registry keys to auto login to the Office user account.
The whole process takes less than half an hour and is almost user proof. (We lock the mouse & keyboard as well.)
Use the Office 2003 Resource Kit tool (ork.exe) to create an .MST file
for the install. This tool is specifically designed for Office 2003.
Use the Office 2003 .MSI file to create your Application Object and add
in the transform. If you are using NAL, you will need to create other
app objects for the icons to become available. Since .MSIs function
best when set as "Install Only" create a folder within NAL and link the
app object to that folder. This way users can verify the application if
We created an Administrative Install point(s) for installation. See:
OFFXP: Supported Installation Methods for Deploying Microsoft Office
We upgraded to the latest patches/SP's on the administration point before starting this process. See:
Deploying Product Updates from an Administrative Installation Point
This creates the Base... then you add on through the AOT from there.
This sets the registry to always look at this point for files.
We are also using the Win2K3 Office Resource Kit. In Creating the MST with the Custom Installation Wizard Step 13 we lock out:
- Microsoft Office Outlook
- Office Shared Features | Alternative User Input (voice/pen recognition)
- Microsoft Office Excel | Text to Speech
- Microsoft Office Access (If Standard Load only)
[We have Access97 Db's so wait until they are converted]
We then put all the icons on the Start Menu under Microsoft Office instead of default.
Step 23 of the Wizard is the Setup Properties
Blank = Current Profile (Installer installs the icons/shortcuts to the ALL Users Dir and Installer will install to the current profile and no other profile can use the application nor can (re)install the application)
1 = ALLUSERS Profile (Installer will install to each profile as needed)
2 = Current Profile (Installer will install to the current user profile all icons/shortcuts however any other users can launch application)
Any modifications to the initial install we use the Custom Maintenance Wizard pointing to the same Administrative Point (ie. to unlock MS Access or other features)
We then create the AOT - we have OfcXPStd and OfcXPPro User groups.
With Read Rights to the Administrative Point Directory.
With Read and File Scan to the PRO11.MSI File only.
Associate the Application to the Groups with the respective MST.
Our helpdesk can drop users in the group and they will get the application and rights needed, however they cannot see all the files/directories.
Use Microsoft's Transform creation tool found on the MS Office 2003 CD. We use MST files to delivery all of the Microsoft applications.
1. We used the Office Resource Kit to create a custom MST file.
Because we needed to install Office on bootup, we created a simple application object "Office Install" with MSIEXEC.exe in the
RUN-OPTIONS > Applications Tab
Path to File: msiexec /i \\ServerName\Office\std11.msi
Parameters: TRANSFORMS=\\ServerName\Office\office11.mst allusers=2 /qb-
This Application Object was set to Force Run and Run Once.
2. We then associated this Application Object to our Workstation Container.
3. We then created simple application objects called "MS Excel" "MS Word" and "MS PowerPoint" for our icons.
Example for Excel:
In the RUN-OPTIONS > Applications Tab
Path to File: %*PROGRAMFILES%\Microsoft Office\Office11\Excel.exe
These Application Objects are associated to the User containers.
4. We then created a ZENworks MSI Application object called "Office MSI" and included the transform file in the Application Object.
5. In the MS Excel, MS Word, MS PowerPoint Application Objects we set RUN-OPTIONS > Application Dependency to point to "Office MSI."
This allows multiple users to log in and use Excel, Word and PowerPoint. It also allows each user to verify and self-heal the applications if required.
I'm still in the testing stages, but I am having success with the
- System - Microsoft Office 2003 Enterprise license
- Office Standard licensed for everyone, Access for 85 people
- ZfD 126.96.36.199 or 42
Looked through a good portion of the Office Resource Kit area on the
Microsoft website to figure out the Local Installation Source, Custom
Installation Wizard, Custom Maintenance Wizard tools.
The problem I was having was that if I made up an MST image for
Standard2003, and another one for Professional2003 (including Access),
the one had to be uninstalled before the other would run, because the
workstation had the one configuration "locked in". The Custom
Maintenance Wizard was the key to that. It also appears to be the key
to delivering patches.
Used LISTOOL to create a compressed CD image for a local installation
source. This caches a 290 MB image of the office install files to the
MSOCACHE directory on the hard drive of the workstation.
Used the Office Resouce Kit's Custom Installation Wizard to set up the
MST transforms for the installation.
Created the Office 2003 standard install, disabling Access 2003.
Set up a ZENworks app to run the setup.exe per the command line function and
parameters shown at the end of the Custom Installation Wizard process.
Used the Custom Maintenance Wizard to set up the CMW file to add Access
2003 to a local installation.
Set up a ZENworks app for Office 2003 Professional running the command line
function and parameters shown at the end of the Custom Maintenance
Copied MAINTWIZ.EXE and MAINTWIZ.CHM from the ORK directory on the
computer I used to make the deployments to the network folder where the
installation point is located.
Chained the 2003 Professional ZENworks app to the 2003 Standard app. This
will, when associated to a workstation, need to be set as "Force run as
user if application is workstation associated". The Office Standard
will run first, followed by Access being added. The adding of access
happens either at the next reboot, or the next time the application
I used the Custom Maintenance Wizard to set up a CMW to remove Access
2003 from a local installation.
Set up a ZENworks app for Remove Access 2003, running the command line
function and parameters shown at the end of the Custom Maintenance
I was able to go back and forth several times, using "VERIFY" in the
app launcher - and if I verified the Professional 2003 app, it would add
Access back in. If I verified the remove app, it would delete Access
Still experimenting with other situations - but this seems to be
I have one app using a custom MST made up from the Custom Installation
Wizard to install everything but Access.
I made another app using the Custom maintenance Wizard to add Access
I did not associate them to anyone or anything.
I told the Access 2003 app it was dependent on the Standard 2003 app
I made a third app for Professional 2003 that only chains the other
two together, being sure that the Standard 2003 goes first.
All are set up to "force run as user if application is workstation
Worked like a charm.
Having read all of the many excellent responses, I wondered why people are using the MSI, instead of Setup.exe.
Simply put: The Setup.exe was designed with System checks and several Command-line switches available.
Our environment consists of:
- 4000 Nodes (XPSP1 & 2000 SP2, 3, 4)
- 10 Geographic Locations (ZEN 4.01 Servers @ All Locations)
- Several Locations have very slow links
- Installed Office Resource Kit (Free)
- Created an Administrative Installation using Setup.exe /a. This creates a compressed image of the Office Installation files.
- Slipstream all Security Updates and the Service Pack into the Administrative Installation.
- Used the Custom Installation Wizard to customize Office to our needs. In our case, we removed Access. We are installing Access as a separate Object (DB conversion permitting).
- Copied the Compressed Office Directory (Image) to all ZENworks Servers.
- Created an object that calls the Setup.exe with these parameters: setup.exe TRANSFORMS=Custom.MST /qb-
- Make sure the %Source_Path% Macro points to the "Correct Path" on the location specific server. Otherwise Setup.exe would try to run from the local machine and do an install of the OS. (Not what we want, eh?)
- Create a VCD Object for Remote, Non-ZEN connected Sites.
- Associated the Office Object by Context.
- Used the Custom Maintenance Wizard to apply product-specific changes such as:
- Feature Installation States
- User Settings
- Add/Remove Custom Files and Registry Settings
- List of Admin. Installation Points
- Security Settings
- Applied that to completed Office Installations which included the Final Access installation.
We are currently looking at importing the Office11.adm file into ZENworks, and using it to complete any policies changes needed. Here is a snippet from Microsoft:
The basic installation process for Microsoft? Office 2003 is the same as it is for Microsoft Office XP and Microsoft Office 2000. The Office Setup program calls Windows Installer to install Office 2003 and related packages. Setup coordinates the installation process from beginning to end, terminating when the last chained package is installed. Because no system file updates or computer restarts are required, installing the Office 2003 client is even more straightforward and efficient than installing previous versions.
The files listed in the following table are often used during an Office 2003 installation.
||Office Setup program.
|| Setup settings file. Located in the Files\Setup folder.
||Office Source Engine installed by Setup.exe. Copies installation files from the source to a local installation source
||Windows Installer. Called by Setup.exe to install Office.
||Windows Installer package. Used by Windows Installer to install Office.
||Windows Installer transform. Used by Windows Installer to customize Office.
||Setup log file. Separate log file generated by Setup for each task.
You run Setup by running or double-clicking setup.exe on the Office 2003 CD or at the root of the installation image. If Office 2003 is not installed on the computer, you can also run Setup by inserting the Office 2003 CD or by typing the following command line:
setup.exe [display settings] [logging settings] [options]
Hope this helps you in making some very important choices for the Installation of Office 2003.
I just set up the process for our organization - Office 2003 using ZEN 4 NAL object.
- Use enterprise version of the Office 2003 software - and an administrative install point on a network share.
- Patch the Administrative install to the newest patch level.
- Download and install the Microsoft Office 2003 Resource Kit.
- Create an .MST ( Microsoft transform file) for each variation of the product install that you need. This MS product works great - you can control just about any option on the install as well as anything the user would see in the TOOL > OPTIONS tab on the App - such as default file directory, font's etc...
Give the APP object file rights to the install folders.
One change I would highly suggest is there is a control in ACCESS to automatically open NON 2003 ACCESS databases in their own format and not ask the user to convert them to 2003 format.
- You can create a separate MST for each flavor of Office you need to install.
- Create a NAL Application MSI object and point it to the appropriate transform file.
I had eleven different sites across a WAN to set up and found that you can copy the original directory, .MSI & .MST files to the other sites and set up new NAL Application objects at each site so the install is done from the local server.
You can use the NAL "Copy and existing object" to duplicate the original install - then you need to use the COMMON > SOURCES tab to change the Package path.
Actually, you probably DON'T want to use the Admin Install method, as was used by Office 2000, and as many here have described using for Office 2003. Rather, you want to copy the whole CD to your network location(s) and do a regular install, making sure that you enable caching and do not delete the cached files. The reason for this is so that you have all your source files available ON the target drive (those are what cache), so in the future when doing updates, you don't have to point to either the ORIGINAL Admin Install point or try and find a CD.
Office 2000 upgrades and patches were a nightmare, due to the requirement to have the SAME Admin Install files (meaning you couldn't upgrade them), and ordinary users without Administrator Rights couldn't change the location of the original files (over a period of 5 years, we actually ended up with three different locations for three slightly different Office 2000 Admin Install points--and, when we pushed a patch to a user computer, invariably he'd be pointing at the wrong Admin Install point, couldn't change the path, and the push would fail). All-in-all, the caching afforded by Office 2003 is not to be ignored.
Other than that, I use Setup, not MSI and a transform, and push out with ZFD 3.2w/SP2 on NW 4.11w/SP9, and it works great.
These are the steps I took here at the Florida Department of Children
and Families in Tallahassee.
We pushed down a batch file using a ZENworks 4.01 NAL object with these
"\\servername and path\setup.exe /settings ENFORCECACHE=1
TRANSFORMS=\\servername and path\mst_you_created.MST /qb-
The first path statement is the place where we copied the entire CD
contents on a network drive.
The Transforms file was created with the Office 2003 resource toolkit
and selected the LIS (Local Install Source) tab and input the CD Key and
EULA agreement. The nice part about this is if someone copies your
entire CD off the network location they still do not have the CD key.
The "ENFORCECACHE=1" switch forces Office to cache the CAB files to a
hidden directory on the local drive called "MSOCACHE". This means
laptop users who are not on the network can still access all the CAB
Some of my lessons learned were when using the run command on the local
workstation, do not use an IP address - use the servername. XP SP2 doesn't
translate an IP address right and the command won't run properly. Also
if the Office resource toolkit you are using doesn't have the Local
Install Source page (where you input the CD key and agree to EULA), that
means you don't have the Office 2003 Kit you have an older version you
can get the 2003 kit at Microsoft?s download site.
Q: This is all fine, and some of these ideas on the site we have used, but is
there a way to deploy Office 2003 using lights out?
A: You could create the MSI and MST files as suggested by others. Then I would create separate App Objects that launch each application within Office 2003. Inside each of these create an Application dependancy (Availability Options) on the Office 2003 installation object. This way you set the Office 2003 application to force run and use lights out to deploy. The shortcuts will not appear until the Office installation has completed.
Q: I have two questions.
I am currently testing the deployment of Office 2003 and have used the Office 2003 Resource Kit to create an OPS file with all my preconfigured settings. During the MST creation, I selected "Get values from an existing settings profile" & browsed to the OPS file I had previously created (Step 9 - "Customize Default Application Settings").
When finished, I used ConsoleOne to create the APO using the MSI & I added the MST under the Transforms tab. I noticed two things after I installed the Office 2003 Standard APO from the NAL.
- My Profile settings contained in the OPS file were not applied.
- Outlook did not install.
Obviously most of you would not want to install Outlook as you would be using GroupWise. However we are testing the Outlook Connector with the GroupWise 7 backend (management decision. Not my preference of course), so I need Outlook to install. Note, this only occurred when I was installing over the top of an Office 2000 installation that did not have Outlook installed. If I uninstalled the older version prior then Outlook installed successfully.
Can anyone tell me how to overcome these two issues?
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.