[dead2sin]

See this thread for more info on this issue:

https://www.afp548.com/forum/viewtopic.php?showtopic=26715

[dead2sin]

I 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

[dead2sin]

Actually, 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.

[dead2sin]

I’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]


Label
com.company.personalizeoffice
ProgramArguments

/Library/Scripts/Companyname/personalizeoffice.sh

QueueDirectories

RunAtLoad
WatchPaths

[/code]

I hope this is helpful for anyone else that has had this elusive Office Setup Assistant issue.

Nate

[dead2sin]

I finally figured this out. I was having the same issue myself when installing using Microsoft’s installers, but I finally nailed this down.

You need the key that Greg mentioned in com.microsoft.office.plist but you also need the following:

2008FirstRunSetupAssistCompleted
1

Once you have both in there, you are golden!

It only took 1.5 years to fix this one 😀

[dead2sin]

This is what I came up with. I borrowed a few lines of bash script from the createUser.pkg that I use for InstaDMG (akinspe’s package). All you do is put this this as a postflight in a payload-less package, edit the adminUser variable to suit your needs and put a proper password_hash file into the Contents/Resources directory within the package. I’m going to test it a bit yet, but it seems to work alright using the method that Greg described. I figure this can be put into munki, then if the password needs to be updated, I can enumerate the package version so that it is an “update” for the original. Thanks again for the ideas Greg.

[code]
#!/bin/bash

#Set Variables
adminUser=adminusername
SCRIPT_DIR=”$1/Contents/Resources”

check_password()
{
if [ -f “${SCRIPT_DIR}/password_hash” ];
then
password_hash=`cat “${SCRIPT_DIR}/password_hash”`

else
echo “password_hash could not be found”
exit 1
fi
}

get_GUID()
{
GUID=$(dscl . -read /Users/$adminUser/ | awk ‘/GeneratedUID/ {print $2}’)
}

change_Password()
{
echo “$password_hash”>/var/db/shadow/hash/$GUID
/bin/chmod 600 /var/db/shadow/hash/$GUID
}

check_password
get_GUID
change_Password

[/code]

[dead2sin]

[QUOTE][u]Quote by: gneagle[/u][p]”I create my user accounts using InstaDMG + createUser, so I can set the GUID to be identical. Could I use OD to manage that shadowhash like I would a plist, or does it not handle that type of thing?”

No, you can’t manage this using Open Directory. You’ll need to find another method to deliver changed versions of this file to all your machines. How do you install software on 400 Macs?

-Greg[/p][/QUOTE]

We generally don’t push software out, its preloaded on the image (all necessary software anyways). If we have to push something out, We would use ARD, but I really hate using it for that. ARD is wonderful for some things, but I don’t think it is the best choice for software management.

Hrmmm, if it can’t be done with OD, then that means I have even more of a business case for using Munki. It would be easy to make a package that delivers the shadow hash. I think I am slowly warming up to your strategy for management Greg 🙂 I’m too used to the Windows way of doing everything, so I try to emulate that in my Mac environment.

Thanks again guys.

Nate

[dead2sin]

[QUOTE][u]Quote by: gneagle[/u][p]1) ssh in and change the password.

2) If all the local admin accounts have the same GeneratedUID, push a new shadow hash file to /var/db/shadow/hash/

3) Write a script that normalizes the local admin account’s GeneratedUID for all machines, then #2.

4) Visit each machine in person and change the password manually.
[/p][/QUOTE]

I create my user accounts using InstaDMG + createUser, so I can set the GUID to be identical. Could I use OD to manage that shadowhash like I would a plist, or does it not handle that type of thing? Not being able to manage admin passwords like AD does is kind of a pain for us (we only have 400 macs, but doing it manually on all 400 is a huge pain).

Thanks,

Nate

[dead2sin]

Thanks for all the useful information so far guys.

Does anyone else have any good info regarding this setup? We are trying to decide between Schema Extension and Magic Triangle, with Schema Extension making the most sense for our setup (4,000+ PCs and only 400 macs).

Thanks,

Nate

[dead2sin]

I’ve need seen that not work. Did you try cutting and pasting this into terminal and pressing enter?

[code]sudo installer -showChoicesXML -pkg /Volumes/Mac\ OS\ X\ Install\ DVD/System/Installation/Packages/OSInstall.mpkg[/code]

Every machine I’ve tried it on (10.6 client) it has worked as well as with retail and OEM discs. I’m not sure what else to tell you. If the machine you are running it on is 10.6.x and you cut and pasted the command above into your terminal and it still gave that error, then the only possibilities I can think of are that either #1 the Install Disc image is bad or #2 something is wrong with your 10.6 box.

[dead2sin]

Also, just curious…are you running the installer command using a 10.6 machine, or is it running another version of OS X?

[dead2sin]

[QUOTE][u]Quote by: sketch[/u][p][QUOTE][u]Quote by: Allister[/u][p]Hey sketch,

The -target flag and path after it is unnecessary.

Allister[/p][/QUOTE]

No difference[/p][/QUOTE]

Try just this:

[code]sudo installer -showChoicesXML -pkg /Volumes/Mac\ OS\ X\ Install\ DVD/System/Installation/Packages/OSInstall.mpkg[/code]

Does that give you any output whatsoever?

[dead2sin]

Thanks for the great info! Its good to know they still support it.

Its ok if a computer can only be in one computer list, I guess a question I should ask then is can you apply a MCX to an AD OU? We sort all our machines into OUs and bind directly to specfic OUs.

Thanks again,

Nate

[dead2sin]

Nevermind, I’m blind.

https://www.afp548.com/forum/viewtopic.php?showtopic=26389 Covered it.

[dead2sin]

[QUOTE][u]Quote by: larkost[/u][p]Note that there is really only one thing that is getting chrooted in 10.6, even with the latest version: the part that runs the JavaScript in distribution scripts. So anything where the problem is with installer scripts (postflight, preflight, etc) is still a problem in 10.6 (but pretty well solved with 10.5). So this will fix problems with the iLife Support Updates (which had not been fixed in 10.5 before this), but will not solve problems with things like Cisco’s VPN installer (old example, I don’t know if it is still a problem).[/p][/QUOTE]

Ah, alright, good to know. I had been having problems with the Security Updates as well as iLife support and I can report that both work flawlessly on 1.6b2. I have always had issues packaging iLife 09 with updates, so I will give that a shot as well with the new version.

Nate

[Author]

Posts