[zanzan42]

I have the exact same problem with one AD user. Crazy thing is, he had this problem originally under Leopard, and after wiping the machine and putting on Snow Leopard, same issue after his first login. I suspect something is peculiar about his AD account that the AD plugin doesn’t like, but haven’t found any good info yet.

[zanzan42]

Ok, I just tested this.

I logged into the machine with the local admin account and removed the admin rights from my AD account using the Accounts pref pane. Here’s what I end up with:

101(com.apple.sharepoint.group.1),20(staff)

I then granted admin rights again using Accounts, and ended up with this:

98(_lpadmin),81(_appserveradm),101(com.apple.sharepoint.group.1),79(_appserverusr),80(admin),20(staff)

So it looks like clicking the button in Accounts does a couple of things which I wasn’t accounting for with dseditgroup. In order to get the same result I’m also going to have to script the command for _lpadmin, _appserveradm, and _appserverusr if I want it to do the same thing.

The weird thing is that my local admin account only has this:

20(staff),98(_lpadmin),80(admin)

Of course, that account got created prior to the machine being bound to AD, so maybe that makes a difference. The Accounts pref pane might be doing different things depending upon whether it’s acting upon a local account vs. an AD account.

Allan

[zanzan42]

I looked in this thread because of a weirdness I experienced recently, which might be related to what you’re seeing.

I had to rebuild my own machine a week ago because of a drive failure, so I took the opportunity to drop a clean image on it rather than restore from Time Machine backup. I use a post imaging script to do a number of things, among them a bind to Active Directory (mobile account with forced local home directory). Under normal circumstances, a tech would set up an end user machine, log the user in to cache their AD credentials, then login with the local admin account and make the user an administrator by clicking the admin button in the Accounts pref pane before delivering the machine to the user.

I wanted to test adding a dseditgroup statement to the scripted process and remove the manual process of making the intended end user an admin. So I tested this process on my own machine. Running the dseditgroup command and adding my AD account to the admin group was successful (even before I had cached AD credentials). Once I logged in with my AD account, I showed up in the Accounts pref pane as an admin (and the box was checked already). So far, so good.

Until I tried to add a printer. Same problem you saw. My cached AD account, even though it was a member of the admin group and showed up as an administrator in Accounts, was not a member of lpadmin. I had to auth using the local admin account. I haven’t had a chance yet to take a look at this further, but hope to this week.

It leaves me with questions: why isn’t membership in admin granting full rights? Does clicking the box in the gui add you to more groups than just admin, and was my use of dseditgroup the problem? or is there something going on with (in this case) 10.5.8 that is different from previous versions?

Allan

[zanzan42]

DNS SRV records are not a Microsoft specific animal. That being said, Active Directory has several requirements revolving around SRV records in order for an AD domain to function. You have no choice but to play in that sandbox if you want AD to work for your Windows machines (and any Macs that might be bound to AD).

If you’re going to be installing a Windows 2003 server anyway, I’d recommend just setting up the AD domain on that (make it the PDC) and let it populate your DNS with the right SRV records.

Zanzan

[zanzan42]

In my environment, it’s about 30 seconds before the “network accounts available” button turns green in loginwindow. BTW, you might want to set your loginwindow to display that as the default rather than the machine name, otherwise you have to click through the other information in loginwindow to get to it. I can’t remember the command off the top of my head, but I originally used the Secrets preference pane add-in to set it that way.

Since my machines are bound to both OD and AD, “network accounts available” shows yellow first (one of the directories the machine is bound to is responding, I’m assuming OD), then goes green after that 30 second wait. Not sure whether it’s an issue of the DCs being a couple miles away in a different building, or if it’s just an issue of loginwindow launching before directoryservices is done preparing itself.

Zanzan

[zanzan42]

According to the MS Office 2008 site, they posted an updated SP1 installer package that works with ARD. Supposedly, they fixed the bug that was causing ARD pushes of the MS package to fail.

Allan

[zanzan42]

My test was successful.

I actually left both ProductKey.bundle and RemoveOffice.bundle in the InstallerSections.plist. I’m not exactly sure what the RemoveOffice.bundle does yet, or whether it’s something I should remove from the InstallerSections.plist, but it didn’t adversely affect the install. I suspect it either installs the Office Uninstaller, or is what gets called if you choose Uninstall Office when in the Office Installer GUI.

After running the InstaDMG build and dropping the image on my USB boot stick, I rebooted and launched Word.

I was not prompted for the product key, so that part of it works fine. However, I *was* prompted to enter a name and company name to populate the OfficePID.plist. While that’s not a huge issue (and might actually be desirable if you want to personalize the install for each user after imaging the machine), I’m going to test adding my customized OfficePID.plist file to the same location in the installer package where SetupInfo.plist is and see if it gets dropped in by the installer as well.

Allan

[zanzan42]

Since we have an enterprise license, a typical installation of Office doesn’t prompt me for a product key. The key is already embedded somewhere in the installer we get from Microsoft.

I wanted to try and track down what mechanism in the Office installer controlled that, and figure out how to tweak it for use with InstaDMG without having to create a second package to drop in the setupinfo.plist.

It turns out that the SetupInfo.plist file is contained in ProductKey.bundle in the installer. The path is:

Office\ Installer.mpkg/Contents/PlugIns/ProductKey.bundle/Contents/Resources/Office/SetupInfo.plist

I don’t have a retail Office installer to look at, but I’m going to guess that it does not contain the /Office/SetupInfo.plist part of the path above. The only item inside the Office folder is the SetupInfo.plist file.

I really don’t want to completely remove the stuff in Plugins, as was recommended earlier in the thread, since I really only want to throw out the stuff that gets in the way of installing using InstaDMG. In addition, I’d need to track down what is controlling the installer and try to modify it such that the only thing it’s calling is ProductKey.bundle.

The file located at:

Office\ Installer.mpkg/Contents/PlugIns/InstallerSections.plist

contains a number of sections which appear to be the order in which the installer calls its functions: License, ReadMe, Target, Package Selection, etc, including ProductKey.bundle. I’ve removed all the sections except for ProductKey.bundle to see what happens.

At the end of the day, if we can come up with a method to simply modify the existing installer to add SetupInfo.plist in the right place and then remove the extraneous installer sections, we’re golden.

I’ll send an update with my testing results when I have them (or as soon afterward as possible, as I’m in Egypt right now and engaged in other things).

Allan

[Author]

Posts