Home › Forums › OS X Server and Client Discussion › Questions and Answers › MCX settings for Office 2011
- This topic has 3 replies, 2 voices, and was last updated 14 years, 5 months ago by
blackholemac.
-
AuthorPosts
-
October 6, 2010 at 2:26 pm #379612
blackholemac
ParticipantI will preface this by referring people to Greg Neagle’s excellent article at the following web site:
This article was VERY useful to our district. We were able to leverage WGM to set our users to save to automatically to 97-2004 formats by default. We were additionally able to suppress the Setup Assistant, Deactivate automatic updates and by capturing the /Applications/Microsoft Office 2011/Office/OfficePID.plist file we were able to identically brand all Office 2008 installs.
Alas, now we move on to Office 2011 Volume License edition. Our district needs to fix a stupid problem we are having with our Exchange mail server and Entourage. We’ve found that the answer to the program seems to be to upgrade to Office 2011 for Mac. This after a very lengthy paid case with Microsoft Tech Support 🙁
Anyway, after the initial shock of having to be on the bleeding edge, I’ve found that Office 2011 isn’t that bad from the user point of view. I’m not quite willing to deploy to users yet as I cannot seem to suppress the setup assistant for users other than the localadmin login.
Steps I’ve taken to investigate/try to solve this:
1. I took Greg’s advice in the article and visited the com.microsoft.office.plist file. I found that Office 2011 stores the setup assistant key as follows (14\FirstRun\SetupComplete integer 1).
2. Again took Greg’s advice in the article and visted com.microsoft.autoupdate2.plist. His article still seems to apply here. The important key is as follows (HowToCheck string manual)
3. Imported both plist files into a new workgroup called “testmachinegroup” in WGM. Removed all keys save for what I talked about from these two plist files.
4. Took my spare Mac Mini, wiped it, installed Mac OS X 10.6.3 from the boot DVD and applied all applicable OS updates. Bound the Mac Mini to OD successfully and added the machine record to “testmachinegroup”
5. Installed Office 2011, ran through the setup assistant as localadmin answering “no” to updates and error reporting and branding the software. I also assume (perhaps wrongly) that setup assistant is copying fonts and other resources to various locations on the machine.
In short: I’m okay with running the Office 2011 setup assistant once per machine, just not for every user that logs in.
I am grateful for any advice and if Greg Neagle is viewing this post, thank you again very much. Hopefully it’s just something simple as I would like to begin deployment on Office 2011 over the course of the next two weeks.
If it helps anyone, I can forward the Microsoft Office 2011 Admin guide from Microsoft. I am still re-reading it for the third time hoping for an answer but not expecting it.
blackholemac
October 14, 2010 at 10:29 pm #379660titanonearth
ParticipantMicrosoft has provided the info:
http://www.officeformachelp.com/office/administration/mcx/
Seems you need the user name and organization name as well.
October 15, 2010 at 12:02 pm #379661blackholemac
Participanttitanonearth,
I want to thank you for this posting. Oddly enough, someone beat you to it offline less than 12 hours ago, but I’m glad to see your post as it corroborates the info they passed along with an MS weigh-in. Here was what they sent me:
http://www.osxdeployment.info/wiki/Office_2011_Settings
Same concept but the original source was unsure of a couple of MCX entries and the MS weigh in uses fewer keys to manage which in this case is a cleaner approach.
Thank you,
blackholemacOctober 20, 2010 at 4:15 pm #379683blackholemac
ParticipantA final note to close this thread with. With the use of MCX and a little bit of scripting I found the way that makes this work well within our environment. Being that this is a forum and I’ve already asked questions, now it is my turn to give answers. I am happy to share my advice, scriptcode and details for those that face this same issue.
[b]PART 1: MCX[/b] During testing I created a new computer group and added my test machine as a member. (We manage policy typically by computer group with a very few exceptions.) In the details tab, I imported the following preferences: com.microsoft.office.plist, com.microsoft.error_reporting.plist, and com.microsoft.autoupdate2.plist. I set the MCX to only manage the following:
com.microsoft.autoupdate2:[code]
[/code]com.microsoft.error_reporting:[code]
HowToCheck
Manual
LastUpdate
2001-01-01T00:00:00Z
[/code]com.microsoft.office:[code]
SQMReportsEnabled
ShipAssertEnabled
[/code]You will notice on the last one that I left out the 14\UserInfo\UserName key. I did that on purpose. If I statically define a user name there, it will brand that on each and every machine. While that seems desirable, it is NOT because then if you wish to use or set up Outlook, you have to remember to change the “Me” contact to the user’s name during setup or every message they send out will come from the statically defined value in the 14\UserInfo\UserName key. Hence the need for second part to this:
14\FirstRun\SetupComplete
1
14\UserInfo\UserOrganization
Company Name
[b]PART 2: SCRIPTING[/b] So okay we have Office First Run suppressed save for the 14\UserInfo\UserName key. You could just not populate this key and Office 2011 will query the user to populate this data upon first run. Perhaps a good idea in an un-managed office setting, but not so helpful in a controlled lab environment.
To work around this issue, I have created a script that needs to be run as the user (NOT ROOT) that defines the 14\UserInfo\UserName key for each user upon logging. I implemented this script using a LaunchAgent at the computer level. Some of the documentation suggest putting this at the user level and only running it once. I wish to have it run and be forced each time (kind of like an MCX control only not using that mechanism)
Here is the code for the script I used to change the 14\UserInfo\UserName key:[code]#!/bin/bash
#declare the variables. We have a magic triangle implementation binding both to AD and OD. We also utilize portable home directories.
username=`whoami`
lastname=`dscl . -read /Users/$username RealName | awk ‘ NR > 1 {print $2}’`
firstname=`dscl . -read /Users/$username RealName | awk ‘ NR > 1 {print $1}’ | tr -d ‘,’`#use PlistBuddy to add the username string and set the value based on the earlier declared variables
/usr/libexec/PlistBuddy -c “Add :14\\\UserInfo\\\UserName string” ~/Library/Preferences/com.microsoft.office.plist
/usr/libexec/PlistBuddy -c “set :14\\\UserInfo\\\UserName ‘$firstname’ ‘$lastname'” ~/Library/Preferences/com.microsoft.office.plist#this script is called by a LaunchAgent so I really don’t want to know about it or inform the user in labs even if it fails
exit 0[/code]
Here is the code for the LaunchAgent installed to /Library/LaunchAgents:
[code]
[/code]
Label
us.in.k12.lsc.PersonalizeOffice
ProgramArguments
/Library/Scripts/Admin/personalizeoffice.sh
RunAtLoad
Finally, don’t forget to load the LaunchAgent:
[code]launchctl load[/code]Now I end this post by saying that this is NOT original work by any means. I created a custom solution for our environment that draws heavily on advice coming from these three websites: http://www.officeformachelp.com/office/administration/mcx/
http://www.osxdeployment.info/wiki/Office_2011_Settings
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man5/launchd.plist.5.htmlI include the launchd man page article because it explains why I chose a computer level LaunchAgent and not a login hook or a LaunchDaemon to call this script.
Hopefully this has been helpful and I thank everyone for helping to answer my questions.
blackholemac
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed