Article

ccwilson's picture
article
Reads:

13900

Score:
1.666665
1.7
3
 
Comments:

6

Distributing Office 2007 Via ZENworks Desktop Management

Author Info

22 March 2007 - 10:45am
Submitted by: ccwilson

(View Disclaimer)

Prerequisites

Prior knowledge and experience will help readers understand and apply the information in this paper, particularly experience in the following areas:

  • ZENworks Application Delivery (NetWare, Linux or Windows) (This was deployed on ZENworks 6.5 SP2.)
  • Microsoft Office 2003, Microsoft Office XP, or Microsoft Office 2000
  • Previous use of Office Resource Kit (ORK)

Creating the Distribution Point

This distribution point is really only for control of the initial Office installation. During the setup, Office 2007 will cache all the setup files to a local disk, and that is what it will look at if extra files, etc., are needed to install components that were not installed as part of the initial installation.

  1. Create a folder for the Office source files at an accessible location on the network server. For example: \\servername\volume-name\Office2007
  2. Insert the Office CD into your CD drive.
  3. In Windows Explorer, select all the files and folders on the CD. Copy the CD contents to the folder on the network. This location becomes your network installation point.

Creating the Custom Installation File

You use the "Office Customization Tool" or "OCT" to customize an installation of the Microsoft Office 2007 Software. This was previously done by running the "Custom Installation Wizard" in Office 2000/XP/2003 resource kit and creating an MST configuration file. To run the OCT you need to type
\\servername\volume-name\Office2007\setup.exe /admin
This will launch the OCT which will allow you to configure the installation. Below are just a few of the items you can specify in the OCT tool.

  • Default Installation Location
  • Default Organization Name
  • Product Key
  • End User License Agreement
  • The level of display that the USER will see during the installation
  • Whether or not to remove previous Office Installations if they are detected
  • Custom Programs to run during the installation
  • Security Settings for each of the Office 2007 applications
  • Setup Properties

Here are the key settings that will allow the installation run with no user intervention at all. Under the "Licensing and User Interface" section of the OCT:

  • The "Product Key" must be entered
  • The "I Accept Agreement" box must be ticked
  • The "Display Level" dropdown box must be set to BASIC
  • The suppress modal box must also be ticked

Once you have specified all the settings, you need to save the configuration to a .MSP file. I have saved my .MSP file to the "Updates" folder that is on the network share like this:
\\servername\volume-name\Office2007\Updates\Office2007Install.MSP

The Updates Folder

Previously when an "Office" service pack came out you would have to download the service pack for an "Administrative install" which would be a .MSP file and then you would have to apply that .MSP to the original office MSI file. The original MSI file for the Office Installation would then get patched to the latest service pack and from then on whenever you ran that MSI file a patched version of Office would be installed.

Microsoft, in their wisdom, has now made this process a whole lot easier for Network Administrators by just allowing us to drop the .MSP file updates for Office 2007 (when they are released) into the Updates folder on our network installation point and these .MSP files will then get processed as part of the installation of Office 2007.

Creating the NAL Objects For Installation

  1. Select the container that you wish to create your Installation NAL object in and create a new "Application."
  2. Choose a "Simple application (no .AXT, .AOT, .MSI file)."
  3. Give your NAL Object a name like Office-2007-Installation
  4. When prompted for the path, specify \\servername\volume-name\Office2007\setup.exe where "servername" is the server you copied your Office 2007 installation files to.
  5. I then leave the Rules screen alone, but you can specify disk space, memory requirements, etc., here if you want to.
  6. Associate the Application to a USER that will be used to test the installation.
  7. Tick Display Details after creation and click Finish.

The NAL object will then open in ConsoleOne and we just need to add a few more settings to complete the Object before we can test it.

  1. Click the "Run Options" tab.
  2. Under the "Parameters" box you need to specify that we will be using a configuration file during the installation, this is done by putting the following:
    /adminfile \\servername\volume\Office2007\Updates\Office2007Install.MSP

The NAL Object can now be tested. You may want to tweak a few other things like putting the NAL Object in a new folder in the NAL window, adding reporting, etc.

Once you are satisfied that the installation has worked successfully then you can create separate NAL objects to Launch Word, PowerPoint, Excel, Access, Groove, InfoPath, OneNote, Outlook, Picture Manager and Publisher by just pointing the NAL object at the exe file for each of the applications. For example, I created NAL objects to point to

  • C:\Program Files\Microsoft Office\Office12\winword.exe -- this will launch MS Word 2007
  • C:\Program Files\Microsoft Office\Office12\powerpnt.exe -- this will launch MS PowerPoint 2007
  • C:\Program Files\Microsoft Office\Office12\excel.exe -- this will launch MS Excel 1007
  • C:\Program Files\Microsoft Office\Office12\msaccess.exe -- this will launch MS Access 2007
  • C:\Program Files\Microsoft Office\Office12\groove.exe -- this will launch MS Groove 2007
  • C:\Program Files\Microsoft Office\Office12\infopath.exe -- this will launch MS InfoPath 2007
  • C:\Program Files\Microsoft Office\Office12\onenote.exe -- this will launch MS OneNote 2007
  • C:\Program Files\Microsoft Office\Office12\outlook.exe -- this will launch MS Outlook 2007
  • C:\Program Files\Microsoft Office\Office12\ois.exe -- this will launch MS Picture Man. 2007
  • C:\Program Files\Microsoft Office\Office12\mspub.exe -- this will launch MS Publisher 2007

There are a few things to be aware of when upgrading to Office 2007. The look and feel of Office as we knew it is gone and we now have a whole new interface to deal with which will require some end-user training to get used to. Also Office now uses the Office Open XML Formats document formats as the default Save option. The new format has been set as the default option to reduce storage space by using the compression features of the new file types as well as to improve ease of recovery.

The 2007 Office release applications can open legacy document formats as far back as Microsoft Office 97. However, earlier versions of Microsoft Office cannot open the new default document formats by default. There is a "Compatibility Pack" out now for previous versions of Office to allow you to open these XML-formatted documents. This can be found here.

I hope this document has been useful to those of you who are looking to deploy Microsoft Office 2007.

Suggestions and Follow-up Questions

Norbert Hefenbrock

Hello Gareth, this is an interesting article for me. But I have some questions.

  1. Why do you create a *.MSP and not a *.MST file? Is it a new feature in Office 2007?
  2. Why you do not use a MSI-Application in ZEN?
  3. What rights on the workstation will the user need for installation. Can I install with user-rights?

Roland Pfenninger

  1. Yes, the Office Customization Tool (OCT) included in the Office 2007 Setup creates an .msp file unlike the earlier Custom Installation Wizard (CIW). I asked a Microsoft Teacher during class what the reason is behind this change - unfortunately he couldn't tell.
  2. Unfortunately you need to start the setup.exe file to install Office 2007. The setup.exe calls then something about 20 different .msi's to install the whole thing, that's why you can't create an MSI-NAL object.
  3. Our users are PowerUsers only (in a WinXP environment) and the install runs fine using the 'unsecure system user' option even from a network share!
  4. Microsoft doesn't recommend removing the local files (on the workstation) after the installation because those local files are more important than in earlier versions of Office regarding Patching & Updating or modifiying the installation.

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.




User Comments

freemeg's picture

How would you do this in an Unattended install?

Submitted by freemeg on 26 November 2007 - 5:38pm.

I've tried setting Force Run on the association and then Run Once in the Application Object Options, but it fails to install.

blackbrow's picture

MSP over MST

Submitted by blackbrow on 10 December 2007 - 3:40am.

I think the change to MSP files allows you to more easily reconfigure the installation. I know the old versions of office allowed you to use the maintenance wizard to configure changes, but I found this tool be more of a hack for updating already installed MSIs. With the MSP you are not limited to the initial settings installed with an MST file.

With the new system you seem to be able to chain multiple MSP, so you could create an MSP for each individual component and create App objects that distribute various combinations of components.

marklar23's picture

Local Machine Privileges

Submitted by marklar23 on 24 April 2008 - 9:21am.

When I get through the installation and try to install on a user under my standard policy, I get an administrative privileges required to install message. I've renamed the Setup.exe to something less generic and permitted the renamed exe to run, but get the same message. How do you deploy the exe to a locked down environment?

scum's picture

hi mark, hrm... the only

Submitted by scum on 12 May 2008 - 11:13pm.

hi mark,
hrm... the only solution i know of to install an applictaion on a locked down workstation is to run the NAL App as either the "secure system user" or "unsecure system user"

once i tried to deploy a script that launched the setup.exe as an alternative user (with fully rights).... nerver worked for me though...

tkp's picture

Distribution of Office 2007

Submitted by tkp on 8 May 2008 - 2:56am.

I just wanted to give my comments on this issue. With Office 2007 it is not possible to ditribute using an MSI object. As described earlier in this tread, you should use "setup.exe" which would launch a silent installation (assuming you have a propper MSP file. ie. in the Update folder). Instead of launching "setup.exe" from the Run optins tab, I decided to have Word, Excel and so on chained to a Office installation object. My Office installation object is configured in the following way:
1. On the Distribution options tab, I have put in a copy of the Office share to a local folder (C:\Install\Off2007) + include subfolders
2. On the same tab, in the Ditribution scripts tab, I created a script like this: C:\Install\OFF2007\setup.exe + in the script location field: %*winsysdir%\cmd.exe /c

What this does, is it copies the office installation to a local folder and installs office from there. The reason I'm copying to a local folder, is that distribution scripts are run in the secure system space, which means that users do not see any of the script commands or command results. Also rights to files on the network share are those of the Workstation - and if the workstation is not imported to edirectory you cannot grant rights. So to make sure it will work I copied to a local folder.

Then I have seperate objects for launching Word (Winword.exe) and so on, which are chained to the complete office installation. So when a user launches Word, office is automatically installed on first use. The next time the user launches Word - word is just started since the complete office object is already installed - the installation script is put in the Distribution scripts (only run while distribting). This gives the abillity to verify the application. which would force run of the distribution script again. Now the user doesn't see the splash screen from the office installation, it looks like a normal ZENworks MSI installation.

By the way this also solves the problem with missing local rights to install the application. I did this in a locked down MS AD environment, where the users have no local righst.

Hspeirs's picture

In addition to the the

Submitted by Hspeirs on 16 September 2009 - 6:36am.

In addition to the the /adminfile <Path to .MSP> , for a completely unattended install you also need to add to the command line:

/config <path to config.xml >

If for example you just wanted to install Word, you'd add:

/config <Distribution Root>/Word.WW/config.xml

For a complete Enterprise Office distribution

/config <Distribution Root>/Enterprise.WW/config.xml

etc

© 2013 Novell