Skip to main content

thus far, we've had only one problem in running InstallLion.pkg via self service or by policy: although it does, indeed, update macs from 10.6.8 to 10.7.4, the problem (as some of you have already experienced) is that apple's installer deletes any local, hidden accounts on the mac in question when updating to lion. and, in our case, the local casper mgmt account on each machine is one of those hidden accounts.



this means that once a mac has been updated to 10.7.x via that mechanism, i can no longer run any other capser policies. and that, in turn, means i have to find a way around this issue. my first attempts were to create a firstboot script that puts back the deleted admin account but...



i'm having problems. our script/agent which runs from it's location in /Library/LaunchAgents is failing with permission errors. and this, even though both the script and the agent are owned by root:wheel and set to permissions of 644.



how are you folks dealing with this issue and what specific solutions have you used to solve the problem on your end?



cheers,



david koff
sysadmin, the j. paul getty trust
los angeles

needs to be a LaunchDaemon not an Agent, Agents are things run by the user at login,

I've got a post on how user accounts are handled in an upgrade:



http://derflounder.wordpress.com/2012/01/04/hidden-users-with-hidden-home-folders-not-migrated-when-upgrading-to-10-7/



Probably the easiest thing to do is to include a launchdaemon / script combo as an additional installer. The launchdaemon tells the script to reinstall the Casper agent via a QuickAdd package at first boot. That'll recreate the needed user.

Interesting. I never knew hidden accounts weren't migrated over during an upgrade. This seems most definitely like a bug. Why the heck wouldn't it retain those accounts? I assume any original OS hidden accounts get migrated just fine, just not ones created manually?

"how are you folks dealing with this issue"



I add packages that create all needed local accounts (in my case a single local admin) to the install using the `customizeInstallESD` tool.



-Greg

greg,



i AM using the customizeESD tool but, i found the answer even as NESSTS was posting the same: i was creating a launch agent, not a launch daemon. as soon as i changed to a daemon, everything started running right away. the issue is how the two items (agents vs. damons) behave, something i discovered here:



http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/DesigningDaemons.html#//apple_ref/doc/uid/10000172i-SW4-BBCBHBFB



thank you all for the feedback. much appreciated.



for the record, our 1stboot script performs the following tasks:



+ re-creates the hidden admin account
+ downloads any available updates from our hosted SuS, including Java installs
+ fixes an AFP issue that our network has with Lion regarding the disabledUAMS
+ reboots

one last follow up for the group: after running the policy via self sevice and including the /sbin/reboot command mentioned in other threads, the policy completes itself and signs off.



if i run the policy unattended via a trigger like "every15", the install kicks off, runs but NEVER signs off. so every 15, the process repeats itself.



has anyone else seen this issue?

Terms & ConditionsCookie settings