- This topic has 8 replies, 4 voices, and was last updated 14 years, 10 months ago by
dead2sin.
-
AuthorPosts
-
May 11, 2010 at 4:12 pm #378569
sgstuart
ParticipantHi All,
I am having some problems with installing MS Office 2008- site license. There was an earlier post, I found that helped alot (39 replies). After taking the MPKG out of the DMG, I found the /Contents/Plugins/InstallerSections.plist and removed the 1st 2 items in the plist, which actually allowed InstaDMG, to install (those 2 pieces were Introduction and Read Me). After that install, I got stuck in loops of launching any office program, and it would ask for registration and license info, and eventually get to the auto update, which I would quit, out of, and then when I launch it again same thing.I eventually found out that the installation put the SetupInfo.plist file at the root of the image /Office/Setupinfo.plist instead of at /Applications/Microsoft Office 2008/Office/Setupinfo.plist . I also found out that the OfficePID.plist did not exist at all on the installation.
So that led me to this file /Contents/Packages/Office2008_en_required.pkg –> Show contents /Contents/Resources/Postflight —> Here is the original unchanged
#!/bin/sh# Get the installed path of the custom icon file
icon_filename=`printf "Icon\r"`
# $RECEIPT_PATH does not give the full path to the receipts, so must prepend installation volume
bom_path="$3/$RECEIPT_PATH/../Archive.bom"
icon_path_partial=`lsbom -s -f "$bom_path" | grep "/$icon_filename"`
icon_path_full="$2${icon_path_partial:1}"# Set the custom icon of the Microsoft Office 2008 folder
parent_dir=`dirname "$0"`
fix_icon_path="$parent_dir/fix_custom_icon"
office_root_folder=`dirname "$icon_path_full"`
"$fix_icon_path" "$office_root_folder"
/usr/bin/touch "$office_root_folder"# Move the OfficePID.plist to the installed location
source_pid_file="$HOME/Library/Caches/TemporaryItems/Microsoft Office 2008/Office/OfficePID.plist"
target_pid_file="$office_root_folder/Office/OfficePID.plist"
target_pid_dir=`/usr/bin/dirname "$target_pid_file"`
if [ -e "$source_pid_file" ]; then
/bin/mkdir -p "$target_pid_dir"
/bin/cp -f -v "$source_pid_file" "$target_pid_file"
/bin/rm -v "$source_pid_file"
fi
/bin/chmod 0664 "$target_pid_file"# Copy the SetupInfo.plist to the installed location
source_setup_file="$1/../../Plugins/ProductKey.bundle/Contents/Resources/Office/SetupInfo.plist"
target_setup_file="$office_root_folder/Office/SetupInfo.plist"
target_setup_dir=`/usr/bin/dirname "$target_setup_file"`
/bin/mkdir -p "$target_setup_dir"
/bin/cp -f -v "$source_setup_file" "$target_setup_file"
/bin/chmod 0664 "$target_setup_file"exit 0
so because I could not see the OfficePID.plist file I changed the code to this. I also placed a copy of a good OfficePID.plist and put it in the same location as the SetupInfo.plist file.
#!/bin/sh# Get the installed path of the custom icon file
icon_filename=`printf "Icon\r"`
# $RECEIPT_PATH does not give the full path to the receipts, so must prepend installation volume
bom_path="$3/$RECEIPT_PATH/../Archive.bom"
icon_path_partial=`lsbom -s -f "$bom_path" | grep "/$icon_filename"`
icon_path_full="$2${icon_path_partial:1}"# Set the custom icon of the Microsoft Office 2008 folder
parent_dir=`dirname "$0"`
fix_icon_path="$parent_dir/fix_custom_icon"
office_root_folder=`dirname "$icon_path_full"`
"$fix_icon_path" "$office_root_folder"
/usr/bin/touch "$office_root_folder"# Move the OfficePID.plist to the installed location
source_pid_file="$1/../../Plugins/ProductKey.bundle/Contents/Resources/Office/OfficePID.plist"
target_pid_file="$office_root_folder/Office/OfficePID.plist"
target_pid_dir=`/usr/bin/dirname "$target_pid_file"`
if [ -e "$source_pid_file" ]; then
/bin/mkdir -p "$target_pid_dir"
/bin/cp -f -v "$source_pid_file" "$target_pid_file"
/bin/rm -v "$source_pid_file"
fi
/bin/chmod 0664 "$target_pid_file"# Copy the SetupInfo.plist to the installed location
source_setup_file="$1/../../Plugins/ProductKey.bundle/Contents/Resources/Office/SetupInfo.plist"
target_setup_file="$office_root_folder/Office/SetupInfo.plist"
target_setup_dir=`/usr/bin/dirname "$target_setup_file"`
/bin/mkdir -p "$target_setup_dir"
/bin/cp -f -v "$source_setup_file" "$target_setup_file"
/bin/chmod 0664 "$target_setup_file"exit 0
Which at least got both files onto the image, however they are still in the wrong location, /Office/SetupInfo.plist.
So what is wrong with Microsofts Postflight code that is not seeing the paths correctly or (what just came to my mind) is this related to the chroot issue? What should I do to fix this? I also believe I need to remove the line of code /bin/rm -v because my OfficePID.plist file keeps getting deleted from the MPKG file where I place it. However, if I can figure out what is truly happening here, maybe I do not need to muck with their code at all.
Thanks,
Steven StuartMay 11, 2010 at 4:28 pm #378570hkim823
ParticipantOffice 2008 was always a pain for me trying to use the native mpkg file.
I’ve resorted to using a snapshot based pkg maker like JAMF Composer to make my Office 2008 pkg file. I setup a computer with Office 08 the way I want it, and then have Composer pick it up, make some edits to the pkg files (i.e. move the user library and documents files to System/Library/User Template/English.lproj instead, so on image creation and when a new user logs in for the first time, those settings will stick with the new user).
To me it’s worth many times the $99 that it costs. $79 I think for educational institutions. Whenever I come across a pkg that just doesn’t work right, I use Composer to make my own custom one.
May 11, 2010 at 5:17 pm #378574Greg Neagle
ParticipantLooking at that Postflight script; it’s going to have problems running correctly under Snow Leopard, which, to be fair, didn’t exist when Office 2008 shipped.
The biggest problem is the reference to
bom_path=”$3/$RECEIPT_PATH/../Archive.bom”
Which simply does not exist on Snow Leopard, as the package is not copied to the Receipts directory, and in Snow Leopard, $RECEIPT_PATH ends up pointing to the original package. It’s possible that this might work, but I doubt it. This change in the definition of $RECEIPT_PATH ends up affecting the definitions of
bom_path
icon_path_partial
icon_path_full
and most importantly:
office_root_folderThe other possible issue is here:
source_pid_file=”$HOME/Library/Caches/TemporaryItems/Microsoft Office 2008/Office/OfficePID.plist”
When there is no GUI user, $HOME is undefined. In this case, it’s not clear to me if there is a valid OfficePID.plist at /Library/Caches/TemporaryItems/Microsoft Office 2008/Office/OfficePID.plist; if not, there’s nothing to copy…
IMHO, the easiest fix is to create a separate package that you run _after_ the Office 2008 install that installs your correct OfficePID.plist and SetupInfo.plist.
May 11, 2010 at 6:12 pm #378576sgstuart
ParticipantHi Greg,
Thank you very much. I think that answers all those questions. I should have mentioned that I am doing these installs with Snow Leopard, but I forgot to mention that. Thank you for understanding that I probably was.
I agree there was nothing under the $home directory, and everything that you are saying makes complete sense. I did not know that $RECEIPT_PATH did not exist in Snow Leopard. I am surprised that everything else appears to install correctly. Again Greg, thank you.I will also try your idea of just creating a package copying those 2 files. That does appear to be the simplest solution to me.
Thanks,
Steven StuartMay 12, 2010 at 10:57 pm #378589sgstuart
ParticipantHi all and Greg,
I was able to get the installer to work, and place things in their appropriate place by changing $RECEIPT_PATH to its absolute path /Library/Receipts/Office2008_en_required.pkg/Contents/Resources.In the appropriate place above, I also kept what I had from my changed script so not using $HOME, and I also had to copy the OfficePID.plist file to the same location as the SetupInfo.plist. This allowed the installation to work.
I am now having one problem left and that is it. How do I get rid of the First Time Run, so it does not ask any user what their name, company… and needing to click on each of those continue buttons, and having to close out of the Auto Update window?
Thanks,
Steven StuartMay 14, 2010 at 4:23 pm #378595Greg Neagle
ParticipantThat hard-coded receipt path probably won’t exist under Snow Leopard.
As for suppressing the Office Setup Assistant:
[QUOTE][u]Quote by: sgstuart[/u][p]Hi all and Greg,
I was able to get the installer to work, and place things in their appropriate place by changing $RECEIPT_PATH to its absolute path /Library/Receipts/Office2008_en_required.pkg/Contents/Resources.In the appropriate place above, I also kept what I had from my changed script so not using $HOME, and I also had to copy the OfficePID.plist file to the same location as the SetupInfo.plist. This allowed the installation to work.
I am now having one problem left and that is it. How do I get rid of the First Time Run, so it does not ask any user what their name, company… and needing to click on each of those continue buttons, and having to close out of the Auto Update window?
Thanks,
Steven Stuart[/p][/QUOTE]June 1, 2010 at 12:07 pm #378660dead2sin
ParticipantI’ve run square into the problem of the first run constantly popping up as well. I had never been able to use the installers provided from Microsoft before, but along with Greg’s documentation on the issue and some poking around, I got it working. For some reason on a fresh install of Office 2008, updated to 12.2.4, managing the “2008\\FirstRun\\SetupAssistCompleted” key wasn’t enough. Even with that set as 1 in the plist, it kept popping up. After some poking around using composer to compare before and after snapshots, I found that the following is also needed for it to skip the setup assistant:
I found that after running setup assistant and filling in all the info, yet ANOTHER first run key was added to the com.microsoft.office.plist file within the user’s preference folder. It added the following key:
2008FirstRunSetupAssistCompleted
1 I added that to the preconfigured com.microsoft.office.plist file that I deliver to the default user template on my images via a package and it still wasn’t working. I wasn’t quite sure why so I started looking at all the before and after setup assistant files and methodically removing them to see which prompted setup assistant to pop up again.
The file that broke it was Microsoft Office 2008 Settings.plist within ~/Library/Preferences/Microsoft/Office 2008/. This file contains the name and organization of the user and apparently it doesn’t like starting word unless its there, so if it is missing, it launches the setup assistant to gather that info. I put in generic information (IT Department for the name, University name for the company) and placed it into default user settings.
It worked flawlessly after doing these two additions to Greg’s directions. As a bonus, I decided that I didn’t like that every user would have generic IT Department as their name in word, so when editing documents and sending them on, it would list eveyone as IT Department instead of who they really are. Because we are bound to AD and use mobile accounts, I decided to pull the RealName info using dscl. I came up with the following script to fix that info upon first logon:
[code]#!/bin/bash
username=$(whoami)
firstname=$(dscl . read /Users/$username RealName | awk ‘ NR > 1 {print $2}’)
lastname=$(dscl . read /Users/$username RealName | awk ‘ NR > 1 {print $1}’ | tr -d ‘,’)/usr/libexec/PlistBuddy -c “Set :1000 ‘$firstname $lastname'” ~/Library/Preferences/Microsoft/Office\ 2008/Microsoft\ Office\ 2008\ Settings.plist
rm ~/Library/LaunchAgents/com.company.personalizeoffice.plist[/code]
Basically this script gets the username, uses it to look up the RealName for that user, then stores the first and last name of that person using awk to clean up the output of RealName (Our format using AD is Last, First Middle). I can’t promise this script will work for everyone as is (In fact, it probably won’t), but I’d imagine with a little bit of tweaking you could make it work in your environment.
After it gets this info, it puts it into the Microsoft Office 2008 Settings.plist file and then deletes the launch agent that ran the script. I store the script in /Library/Scripts/Companyname and then have the LaunchAgent in the default profile so whenever someone logs in for the first time, it runs the script, which deletes the launchagent after its completed its thing.
The LaunchAgent I used is here:
[code]
[/code]
Label
com.company.personalizeoffice
ProgramArguments
/Library/Scripts/Companyname/personalizeoffice.sh
QueueDirectories
RunAtLoad
WatchPaths
I hope this is helpful for anyone else that has had this elusive Office Setup Assistant issue.
Nate
June 2, 2010 at 12:56 pm #378667dead2sin
ParticipantActually, scatch that script for fixing the name. I was testing it and apparently the first person that opens word, their name gets set for EVERYONE! I have no idea where it stores this information, as the name is correct in the User’s pref files. This is really quite annoying that microsoft would make it function like this. It looks like it is back to setting a generic name to register office to and making customers put that info in manually. This is a terrible solution and I hope we can figure out a way around it.
June 2, 2010 at 2:39 pm #378669dead2sin
ParticipantI figured out a way to avoid this issue. Apparently for some reason, when the first admin user on a machine opens Office 2008, it creates a file: /Applications/Microsoft Office 2008/Office/OfficePID.plist
This file is an exact copy of the file found in that User’s preferences. For no particular reason, if OfficePID.plist exists, Office uses the information found there regardless of what information is in the User’s preferences, which is why my above script wasn’t working for anyone after the first user.
My solution (although rather hackish) is to touch an OfficePID.plist file before anyone opens Office and make sure the permissions on it are chmodded to 000 so no one can create or modify that file. After doing this, Office reads the user preferences reliably. This seems to work without messing anything else up, but I’ll continue to test it. If anyone else gives this a shot, let me know if it works for you or not.
Nate
-
AuthorPosts
- You must be logged in to reply to this topic.
Comments are closed