how to create DMG of office 2011

[tcandela]

What is the best way to make a .dmg of Office 2011 with only certain apps installed (Word, powerpoint, excel etc) and not all that other garbage that comes with it, basically I can pick/choose what applications will be installed, then create the .dmg

I am saying .dmg because I also want to have it be uninstalled via policy, so my understanding is to create a .dmg and index it ??

what about FTU/FEU ?

[dpertschi]

Office is one of the few apps I use Composer to snapshot. Works for me.

I would caution excluding content though. Some time back, I excluded Outlook and Lync because we used Lotus Notes. Then when the company switched over to Exchange and Outlook- it was a huge hassle to deploy just those apps. AND I had to repackage Office to include for new machines.

Deploy everything and restrict usage of whatever you don't want used.

[bentoms]

We deploy the PKG.. If you want to pick what to deploy, you can use the choices.xml

[mm2270]

The installerChoicesXML file is the route I would take as well if you want to customize the install using the standard check boxes that show up in the Installer.app.
If you're doing something beyond that, like ripping out things after the installation that aren't part of the standard choices, for one, its kind of asking for trouble, and two, you'd have no choice but to use a Composer snapshot if that were the case. Snapshots can work, but aren't particularly pretty.

[frozenarse]

Another vote for the XML route. That is what we use.

[Tssadmin · Accepted solution]

Just did this a few hours ago.
1. Used composer to create the snapshot.
2. After snapshot I went into the post image and deleted items I did not want.
3. Create the .dmg added it to Casper.
4. pushed it out with a policy.

[tcandela]

@Tssadmin the way you did it is the way I am considering. Did you build your DMG from a clean system? If I build the DMG on a Mavericks system it should be good on Yosemite?

I read about the installerchoicesxml file a couple days ago, maybe I'll look into it more.

[tcandela]

This site gives step by step instructions on three ways to deploy office 2011. The third way is called 'scripted' using the choices.xml, but what about having office 2011 all updated using this method?

Snapshot composer method I can have it fully updated when building the package. Can I have it fully up to date if I use the choices.xml method?

http://www.officeformachelp.com/office/administration/deployment/casper/

[Poseiden951]

Build mine on 10.9, works fine on 10.10

[RobertHammen]

@tcandela, no, you'd need to use one installer (latest VL one was 14.3) and an updater (14.4.8).

Should be no issue between 10.9 and 10.10. Office is pretty OS-agnostic.

Like anything else with Composer, watch folders other than /Applications and /Library.

[tcandela]

@RobertHammen so are you also basically saying to also go with Composer to create the Office 2011.dmg to deploy?

snapshot, then install 14.3 and updater, (remove any folders ex; communicator app etc..) click build and I'm done ?

[tnielsen]

You can be lazy like me and simply push the 14.3 installer then run the latest update. 2 part process but man is it easy.

[RobertHammen]

I've used both approaches. It depends on the environment and time allowed. Both have worked. Maybe in your case, because you wish to modify what is installed, if you're unfamiliar with the InstallerChoices.xml and under a time crunch, you want to go ahead with the snapshot + update. BTW, the 14.3 VLA removes Communicator and adds Lync, FWIW...

[mm2270]

You could do it all in one package built from Composer. Basically, get the latest volume license installer version to ensure you're not installing something really old like 14.0.0. Drop that package. along with the current 14.4.8 updater into a folder in tmp/ called something like "Office_Install"
Create your choices.xml file according to the instructions shown on the OfficeforMac site and also drop that into the same folder in tmp/

Then create your Composer Source by dragging those 3 items into Composer. Now create a postinstall script that uses command line installer to first install the 14.3 full installer mpkg and also use the choices.xml file to customize the installation, and then run the 14.4.8 updater installer from that same path. All of this would be in one postinstall script.

The total installation time will likely take longer than just a Composer capture to DMG might, but in the end you'll have a much cleaner installation. Making it into an actual .pkg installer will also mean it can be used outside of the Casper Suite, as opposed to a .dmg.

As for uninstallation, I would go the scripted route. The same OfficeforMac site has a really good script for uninstalling Office 2011 that I've used dozens of times during tests and it has always worked flawlessly.

However, as Robert Hammen mentions, all of this really depends on how comfortable you are with making that choices.xml file and a postinstall script to utilize it.

[jhalvorson]

I use Composer only because the resulting PKG installs faster, then creating a single bundled installer. I've created a single installer using Packages that first installs Office 14 SP3 and then 14.4.x updater, but it takes longer time for it to install then a pkg made in composer.

Here's what has worked for us since we've been deploying Office 2011.

Setup a computer with a clean install of Mac OS X. Log in as a Admin account; not necessary to be root.
Open Composer, select New Package - Normal Snapshot. Name it: Microsoft_Office_2011-14.4.8
Install Office 2011 SP 3 using the install mpkg from Microsoft
Complete the Office Assistance, but bogus info since we will delete the Users folder later on
Check for updates via Help menu or download directly from Microsoft and install.
Open Lync and and check for updates - for some reason it's not included when you update the Office suite.
Quit all Office apps.
Within Composer, click "Create Package Source" to take the final snap shot
Delete the following files/folders
/User/xxxxusername
/Library/Application Support/.blahxxxxxx..... (it's a long random character file name.)
/Library/Preferences/.blahxxxxxx..... (it's a long random character file name.)
For both /Applications/Microsoft Office 2011 and /Applications/Microsoft Lync.app, set the owner to "root" and the group to "wheel". And click the gear to "Apply Owner and Group to" for both.
Click the Build as PKG.

As you can see, I've done nothing to customize Office or avoid the Office setup assistant for our users. I have a second package that will install our custom template documents.

[tcandela]

I was given an office2011standard.iso so when I run it , it contains a .pkg. I drag that to the desktop and When I run the showchoicesXML command on the .pkg nothing happens.

To test my options , If I start to install I can customize what gets installed by clicking custom install. Looks like I can uncheck 'Microsoft document connection' 'Microsoft lync'

Maybe the snapshot way is best?

[daniel_behan]

I use a DMG so I can prep an Office Identity to use the Exchange Setup Script at:
http://www.officeformachelp.com/outlook/exchange/setup-script/

and the Lync Setup Script at:
http://www.officeformachelp.com/lync/administration/setup-script/

[foigus]

@tcandela Not a Casper user, but I'll take a swing.

The first thing to remember when playing with Installer Choices is that "installer" will react to the software that's already installed on the target disk. Make sure you're doing this testing on a computer without the software of interest installed (e.g. your startup disk with Office already installed) otherwise you may get weird results due to installer (properly) reacting to what's already there.

The proper installer switch (now) to determine available choices via "installer" is no longer "showChoicesXML" as mentioned here, it's "showChoiceChangesXML" (see "man installer"). The Office for Mac Help page is centered around an older version of InstallerChoices that simulated faux "clicks" in Installer.app--the newer format (de)selects specific choices in the pkg.

To see the available options that are available with the newer format:

installer -showChoiceChangesXML -pkg /Volumes/Microsoft Office 2011/Office Installer.mpkg -target / > ~/office_choices.plist

This outputs a plist-formatted list of choices and three attributes around them:

• "visible": Whether or not the choice is visible (e.g. listed) in the GUI Installer.app
• "enabled": Whether or not the GUI Installer.app allows the state of the choice to be changed (i.e. unchecked if it's checked, checked if it's unchecked)
• "selected": Whether or not the choice will be installed

The only attribute you're trying to really modify is "selected" (everything else is Installer.app GUI trimmings), but the other two attributes are important since you really want to determine the intent of the pkg developer. For example, if the pkg developer doesn't make a choice "visible" in Installer.app it's a pretty good bet that the developer doesn't want (and won't support) that Installer Choice being disabled.

So let's trim down the giant plist above to just the choices:

installer -showChoiceChangesXML -pkg /Volumes/Microsoft Office 2011/Office Installer.mpkg -target / | grep -A1 choiceIdentifier | grep -v choiceIdentifier | sort | uniq

Which outputs in part:

<string>appsupport</string>
<string>automator</string>
<string>brazilian</string>
<string>catalan</string>
<string>communicator</string>
<string>czech</string>
<string>danish</string>
<string>dcc</string>
<string>dock</string>

Note your output may be slightly different, due to Microsoft swapping Communicator for Lync and other various changes to the Office 2011 installer.

Take a look at the various choices output by the above command--I'm going to guess that by following your nose* you'll be able to find the choice name that you want. Since you haven't specified what you're trying to remove, I'll choose "communicator" for this discussion. Go look at the "office_choices.plist" document made above and search for "communcator"--there is the following snippet of XML:

        <dict>
                <key>attributeSetting</key>
                <true/>
                <key>choiceAttribute</key>
                <string>visible</string>
                <key>choiceIdentifier</key>
                <string>communicator</string>
        </dict>
        <dict>
                <key>attributeSetting</key>
                <true/>
                <key>choiceAttribute</key>
                <string>enabled</string>
                <key>choiceIdentifier</key>
                <string>communicator</string>
        </dict>
        <dict>
                <key>attributeSetting</key>
                <integer>1</integer>
                <key>choiceAttribute</key>
                <string>selected</string>
                <key>choiceIdentifier</key>
                <string>communicator</string>
        </dict>

So the "communicator" choice is "visible" (=true) in Installer.app, it can be changed ("enabled"=true), and it's set to be installed (in this case by default) since it is "selected"=1. Excellent--the pkg developer intentionally allows the user to change the state of this choice. What we can do is generate a plist-formatted file (let's call it "office_ccxml.plist") to set "selected" to false for the "communicator" choice:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
        <dict>
                <key>attributeSetting</key>
                <integer>0</integer>
                <key>choiceAttribute</key>
                <string>selected</string>
                <key>choiceIdentifier</key>
                <string>communicator</string>
        </dict>
</array>
</plist>

Let's make sure this is a valid plist:

$ plutil -lint ~/office_ccxml.plist 
/Users/admin/office_ccxml.plist: OK

and then offer that plist to installer to evaluate against the Office pkg:

installer -pkg /Volumes/Microsoft Office 2011/Office Installer.mpkg/ -showChoicesAfterApplyingChangesXML ~/office_ccxml.plist -target / > ~/office_with_choices.plist

Assuming we get no errors, let's compare the two changes:

diff -C5 ~/office_choices.plist ~/office_with_choices.plist

and get an output such as:

*** /Users/admin/office_choices.plist   2015-04-04 12:17:14.000000000 -0500
--- office_with_choices.plist   2015-04-04 12:39:52.000000000 -0500

*** 18,28 ****
        <key>choiceIdentifier</key>
        <string>office</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
!       <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>office</string>
    </dict>
--- 18,28 ----
        <key>choiceIdentifier</key>
        <string>office</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
!       <integer>-1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>office</string>
    </dict>

*** 234,244 ****
        <key>choiceIdentifier</key>
        <string>communicator</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
!       <integer>1</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>communicator</string>
    </dict>
--- 234,244 ----
        <key>choiceIdentifier</key>
        <string>communicator</string>
    </dict>
    <dict>
        <key>attributeSetting</key>
!       <integer>0</integer>
        <key>choiceAttribute</key>
        <string>selected</string>
        <key>choiceIdentifier</key>
        <string>communicator</string>
    </dict>

Excellent--the "communicator" choice is now no longer "selected". But what is this change in "office" from "1" to "-1"? Turns out "-1" represents a half-checked box (where some sub-options are selected and some aren't). In the GUI this would be represented by a "dash" in the box rather than a checkmark.

One other thought--you may very well be helped by having a second computer with the GUI Installer.app open with the desired pkg waiting installation. Some of the hierarchical decisions are a lot easier to visually understand from Installer.app rather than from the text output of "installer".

Using/plumbing a ChoiceChangesXML file into an installation will be a lot cleaner than installing the entire suite, nuking a few things, and then snapshotting the result. Snapshotting a modified suite will result in the pkg receipts not matching the installed software and possibly other undesirable outcomes. As to how exactly to plumb ChoiceChangesXML into Casper, I leave you in the able hands of @bentoms and others here.

For further reading, another discussion of ChoiceChangesXML and Office is here, and yet another discussion of ChoiceChangesXML is here.

cc'ing @talkingmoose so he'll see this answer as well.

- Patrick

*And if your nose isn't working, open the pkg in Pacifist to examine the structure. Hopefully your choices aren't "choice0", "choice1", through "choice9".

[tcandela]

@foigus i tried all the things you mentioned good stuff.

Can't I just output the file to the desktop ( -showChoicesXML), edit that and apply it?

I output it to the desktop and I could simply put 0 in 'selected' for the things I don't want installed

[foigus]

You can edit the output of "-showChoiceChangesXML" and end up with a valid choice changes XML file. Note that the editing of my full "-showChoiceChangesXML" to a valid choice changes XML took it from 846 to 14 lines (the file above where I disabled the "communicator" choice).

While it's still likely possible to use the faux clicking method of the earlier choice changes files, it's probably more straightforward to disable choices via the method I described.

[tcandela]

@foigus i see now what you're saying, I just have to indicate in the choices.xml the options I want NOT installed. If I add also Lync, would I add the <dict> selected </dict> for lync under the </dict> of communicator?

Is .xml and .plist considered the same?
If .plist is used in the installer command instead of .xml will it make a difference?

[foigus]

You indicate in the choice changes file the options you'd like changed in the pkg, whether selecting or deselecting them (in this case you're deselecting them).

Add as many dicts to the array as needed, however make sure you're acting against the actual options in your pkg (as @RobertHammen mentioned, older Office 2011 installers include Communicator, while newer Office 2011 installers include Lync).

Regarding file naming, as long as the ChoiceChanges file is a valid plist, it can be named with a .plist extension, a .xml extension, any extension, or none at all.

[talkingmoose]

Good stuff @foigus! I'll plan to update this information using the method you've described.

[tcandela]

@foigus - I created a policy with a myOffice2011choices.plist (removing a few items). I zipped up the office2011installer.pkg and the myOffice2011choices.plist together, then a separate office2011Update1448.pkg was zipped. The policy places both these zipped files to /private/tmp and then a script unzips and installs both the installer (with the -applychoicesXML) and then the upgrade package. Works perfect.
I used composer to create this .

[tcandela]

when an office 2011 dmg is created via Composer, do i have to remove any user files prior to creating the .dmg ?

i installed office, used the customization option and weeded out lync, outlook etc..., after it finished installing I ran Word and went through the prompts (no to auto updates, no to improvement program ....). Then I clicked composer to do the second snapshot. After this second snapshot, and prior to creating the dmg, should any files be removed?

I want it to FUT, FEU to avoid users getting those prompts the first time they run word, excel or whatever.

I created the .dmg and deployed it to test computers and it works fine, but i'm just curious if i had to remove any files prior ???

[bpavlov]

@tcandela That's taking an axe to do the job that should be accomplished with a surgical knife. What I mean is that you are literally copying all preferences without any regarding to what preferences are actually being stored in those plist files. Find out what preferences and settings exactly you want and where those preferences are stored in the plist. Use Composer to do a before and after snapshot if you must to determine where the plist are stored each time you change a setting in Word or Excel and so on. Then create a plist with those preferences you want and use a tool like MCXtoProfile to create config profiles to manage those preferences.

I'll provide this to get you started but you should really look at what I mentioned and avoid creating snapshots like that. Do the handwork now and learn the minutia of every little thing that's changing when you set a setting so that you don't have to kill full preferences for users.

Description
Defaults command to create plist with appropriate entry

Disable Office autoupdate defaults write com.microsoft.autoupdate2 HowToCheck -string "manual" Disable sending error reports defaults write com.microsoft.error_reporting ShipAssertEnabled -bool false Disable sending error reports defaults write com.microsoft.error_reporting SQMReportsEnabled -bool false Hide Word document gallery defaults write com.microsoft.office "14File New StateFNMSWD" -int 0 Hide PowerPoint document gallery defaults write com.microsoft.office "14File New StateFNPPT3" -int 0 Hide Excel document gallery defaults write com.microsoft.office "14File New StateFNXCEL" -int 0 Disable First Run assistant defaults write com.microsoft.office "14FirstRunSetupComplete" -int 1 Set the full name of user defaults write com.microsoft.office "14UserInfoUserName" -string "$FULLNAME" Note: $FULLNAME is specific to casper and will only work if you create config profile and deploy it through casper using this variable. It will pick up the assigned user's name for the computer from Casper. Set the organization name defaults write com.microsoft.office "14UserInfoUserOrganization" -string "Company Name, Inc." Enable expanded printing dialog defaults write com.microsoft.office.setupassistant PMPrintingExpandedStateForPrint -bool true Hide Excel welcome window defaults write com.microsoft.Excel "14Microsoft ExcelHide Welcome Window" -int 1 Enable expanded printing dialog defaults write com.microsoft.Excel PMPrintingExpandedStateForPrint -bool true Enable auto recovery defaults write com.microsoft.Excel "14Microsoft ExcelAutoRecoverEnabled" -int 1 Set auto recovery time defaults write com.microsoft.Excel "14Microsoft ExcelAutoRecoverTime" -int 5 Hide PowerPoint welcome window defaults write com.microsoft.Powerpoint "14OptionsOptionsHide Welcome Dialog" -int 1 Enable auto recovery defaults write com.microsoft.Powerpoint "14OptionsOptionsSaveAutoRecoveryInfo" -int 1 Set auto recovery time defaults write com.microsoft.Powerpoint "14OptionsOptionsFrequencyToSaveAutoRecoveryInfo" -int 5 Enable expanded printing dialog defaults write com.microsoft.Powerpoint PMPrintingExpandedStateForPrint -bool true Hide Word Welcome window defaults write com.microsoft.Word "14OptionsHide Welcome Dialog" -bool true Enable expanded printing dialog defaults write com.microsoft.Word PMPrintingExpandedStateForPrint -bool true Disable What's New window defaults write com.microsoft.rdc.mac show_whats_new_dialog -bool false

[tcandela]

@bpavlov - this was a clean installations of yosemite and office 2011 (up to date) only a single user account on the computer.

I see talks of MCX profiles but don't know what it is, where to configure them ... etc..

why would the '' defaults write com.microsoft.......... that you supplied make a difference if the dmg i made already has preference changes that FUT/FEU will get ?

the .dmg i created and deployed to test machines seems fine and working great

[bpavlov]

@tcandela The problem with taking snapshots of a full plist is that you are literally copying the entire plist file (all preferences) over to each user. What happens if there is hardcoded path in the plist path that other users would not have access to? What if it's a setting that you didn't really mean to set? These are some of the issues that can come up with that approach: you end up copying preferences that you may not have intended to copy. It may work in most cases, but it only takes one situation for where it does not work and suddenly you're wondering where things went wrong.

For example, in the case of Office 2011 if you literally copied the preferences as they are after having 'configured' Office to your liking, you have literally hardcoded the first and last name values for each user. Seems unimportant, right? But did you know that Microsoft uses that information so that applications can track who makes changes to documents (this is helpful for example if you've ever worked in Word and reviewed documents or make use of SharePoint)? If your environment makes use of that future, you most definitely do not want to have that value hardcoded with something generic such as MYCOMPANYNAME.

Or as another example, lets say you set the AutoRecovery folder to /Users/jsmith/random/path/ for one of the Office applications. However, a new user (jdoe) logs into the computer, and they do not have access to /Users/jsmith/random/path/. That's a bit problematic. Now, imagine if jsmith doesn't even exist on each computer. I'm not sure where Office would try to create a recovery file, but I definitely don't want to find out in a worst case situation that the Auto Recovery feature was never working to begin with.

By finding out that specific preference you want to change there are a few benefits:
-you learn how the specific preference being changed in the plist file
-you can now create a new plist specifically for the preferences you want to set
-you can try to convert it into a configuration profile to manage using the method apple is trying to get everyone to use

The commands I gave you change specific preferences and nothing more. However you probably want to change the location where the defaults command is writing to otherwise the command as is will write to ~/Library/Preferences which you may not want if there are other preferences already there and you are looking to make a config profile out of a plist.

Learning how to make configuration profiles is rather simple. [https://github.com/timsutton/mcxToProfile](MCXtoProfile) is a free tool by @timsutton to convert MCX or PLISTs into configuration profiles. And Casper also supports creating custom configuration profiles as well from plist files (Computers tab -> Configuration Profiles -> New -> Custom Settings -> Configure).

Hopefully this makes sense.

[kwsenger]

Question:

When we set FUT and FEU on our policy using our Composer MS Office 2011.dmg, new users are missing the following folders in their newly created user ~Library folder.

Calendars
ColorSync
components
Dictionaries
KeyBindings
Keychains
Mail
QuickLook

When we simply delete these folders 0kb folders, log out and log back in and the folders are recreated.
Has anyone come across this and have a fix?
It only is happening with our MS Office .dmg

Thanks
Karl.

[talkingmoose]

@kwsenger, if you view/edit your MS Office .dmg, what do you see in it? Do you have a Users folder? Those folders are not part of Office 2011 for Mac. If you see them in your package, then delete them. They are cruft (files unrelated to the application you've packaged).

You'll also need to remove them from your User Template folder in the System folder to prevent future users from getting the unwanted files.

[kwsenger]

@talkingmoose, Thanks for the response.
When we mount the .dmg we have a ~user folder which contains a few ~/Application Support directories and ~/Library/Preferences setup .plist files so when a new student opens Word, Excel or PowerPoint for Business class, they do not see any setup screens and the apps simply open. If we remove the ~users folders we can simply make a .pkg since the only other folders are /Applications and /Library folders.

Thanks Moose.
Karl.

[areimer]

For people coming to this topic today, the "accepted solution" would be considered worst practice today. One of these two options would be best:

1. Microsoft now offers individual app installer packages. Just download the ones you want and add them to a policy.
2. Write a policy that caches the full Office installer and an appropriately-created choices.xml file (see post by foigus above) on the target computer and then runs the installer command with the -applyChoiceChangesXML option.

If you think the choices.xml option should be a part of installing packages in Jamf Pro (like it is in Munki), upvote this feature request.