[Greg Neagle]

I can’t help you with ClearReg.dmg, but here’s a package that does the exact same thing:

https://dl.dropbox.com/u/8119814/DisableSetupAssistant.pkg.zip

[Greg Neagle]

I wouldn’t call that a brute force method. I would call that the correct method.

A package is an object that the installer uses to install files and directories with specific owners. groups, and permissions.

That’s what you wanted to do…

[Greg Neagle]

Search Google for “automated install of lion”

-Greg

[Greg Neagle]

I worry that you might be in over your head if accessing the root-owned User Template is confusing. Yes, you’ll need root privileges; no, you don’t need to login as root if you don’t want to.

[Greg Neagle]

Then if you modify the default user template on the server, all new accounts created after that will have their home folders created to match the altered default user template.

/System/Library/User\ Template

[Greg Neagle]

Yes, it is possible.

The exact mechanism depends on many factors, but boils down to “how are the network home folders initially created for your users”? This, in turn, might be related to the initial account creation — how are your network users’ accounts created (and where)?

What type of network directory service are you using?
Where are your network homes hosted?

-Greg

[Greg Neagle]

[QUOTE][u]Quote by: Confusion[/u][p]Thanks for the help allister i really appreciate it.
I have tried joining the macenterprise group numerous time and have emailed the group owner to get membership but it never gets granted so all i can do is read them.
I have just sent off another request[/p][/QUOTE]

You cannot join the MacEnterprise [b]Google Group[/b]; it is a read-only archive of MacEnterprise mail list messages.

You [b]CAN[/b] join the MacEnterprise [b]mailing list[/b], and the link to do so is at the bottom of every single message to the list.

[Greg Neagle]

/private/tmp is usually cleared out on boot, so most likely the file is not found because it was deleted on the first boot of the newly imaged machine.
Consider using a different place to cache the package.

[Greg Neagle]

Yes.

InstaDMG wants packages and only packages.

To install software that is not distributed in package format, you must package it.

[Greg Neagle]

[QUOTE][u]Quote by: Kim+Young[/u][p]At this point in my education I am looking to make only one change at a time. Any more than that will just confuse me. I got a standard user created with the create user pkg. Now I hope to create a managed user. I do not care about any other customizations at this time. If “0” gives me a standard user and “1” gives me an admin user, what value give me a managed user?[/p][/QUOTE]

No one value gives you a managed user. In order for a user to appear as “managed”, it must have one or more MCX policies applied. In other words, you must manage something about the user. It’s not just a binary on/off switch.

[Greg Neagle]

com.apple.sidebarlists is the correct preferences domain. The manifest doesn’t list _everything_ you can manage. You’ll have to manually configure a sidebar and then import the plist and look for the keys you need.

[Greg Neagle]

[QUOTE][u]Quote by: catfeetstop[/u][p]I’m new to enterprise Mac administration and I’m trying to figure out the best way to handle admin rights on our client Macs. I’ve looked around already and I know a lot of these questions have been answered elsewhere but I’m still having a hard time understanding the topic. If you have references to those other answers I’d love to see them. I still have some questions that I was looking for your input on and would love to hear your experiences. We’d like to create the best user experience possible and we don’t think our users will be happy if every time they want to install/update software or use the Mac AppStore they have to wait for a Sysadmin’s interaction.

Currently in our setup, our users login to their Macs as “standard” users using their AD credentials. We have our AD schema extended to allow MCX management through Workgroup Manager. Our Sysadmins administer the client computers because of the “Allow administration by…” option of the AD plugin. We have a growing number of Macs in our business and my questions are:

1. How do you guys handle admin accounts for client computers?[/QUOTE]

We give admin rights to regular users only if absolutely needed.

[quote]2. Do you allow all users to be admins on the computer so they can install/update software?[/quote]

No.

[quote]3. If they’re “standard” users, do you just push the software/updates to them individually through Apple Remote Desktop (or something similar) when requested?[/quote]

Yes. We use munki for this.

[quote]4. Do you physically go to their computer and type in your Sysadmin credentials to install/update software when requested?[/quote]

No.

[quote]5. Do you allow admin access and use some sort of application whitelisting/blacklisting system allow/disallow certain apps?[/quote]

There’s two unrelated concepts in that question. We don’t use application whilelisting/blacklisting. Ineffective with admins, if that’s what you’re asking.

[quote]6. Do you use the ~/Applications folder?[/quote]

No. Users might.

[quote]7. Should each client computer have a local admin account in which we give each user the credentials to so they can install/update software? If so, can we disable login for this admin account?[/quote]

Both are possible approaches.

[quote]8. Is there a way to have a limited admin user that can only administer certain features? (i.e. install/update software only)[/quote]

Not trivially.

[quote]9. Does Munki help with this dilemma and if so, how? (I’m not totally sure how Munki works or what it’s for)[/quote]

If your ‘dilemma’ is only about installing software, then yes, munki can help. munki installs software.

[quote]10. Do you know if any of this will change when Lion comes along? If so, in what way are things changing?[/quote]

NDA. But it’s safe to say that concepts of “standard” and “admin” users will still exist in Lion.

[quote]I think those are all the questions I can come up with. I hope all this makes sense, I know the questions are a little repetitive. Thanks in advance for all your help, I couldn’t do any of this without you guys![/quote]

[Greg Neagle]

Parental Controls adds MCX info into the local DS record, and therefore is incompatible with Local MCX at the user level (both things assume they have complete control of the user’s MCX info).

Possible workarounds include:

– Using Local MCX only at the computer/computer group level, and Parental Controls for the user-level stuff.

– Avoiding Parental Controls altogether and using only Local MCX.

-Greg

[QUOTE][u]Quote by: Ebonfyre[/u][p]My pkg is created by launching WGM on a newly imaged unit, making the changes I wish, and then adding the plists in /private/var/db/dslocal/nodes/Default/users for each of my users into a pkg using Composer (failed horribly using PackageMaker). This method seems to have worked perfectly for many months.

I’ve confirmed using “diff -y” on a before and after copy of a user plist that turning on Parental Controls in this case does completely destroy everything in the mcx_settings section of the plist.

This seems like a huge pitfall against this method of preference management. There are many innocent and legitimate reasons to want to turn Parental Controls on and off.

The user in question has the following preferences managed:
Dock: Dock Items: Once
Media Access: Other Media: Disc Images: Require Authentication: Always (I think this is what is causing the SystemUI Server bug)
Parental Controls: Content Filtering: Hide Profanity in Dictionary: Always
System Preferences: (uncheck show) Expose&Spaces, Sharing, Software Update, Startup Disk: Always[/p][/QUOTE]

[Greg Neagle]

Short answer: no.

Long answer: you could use something like crankd to be notified when your network configuration changes, and then a script could set the CatalogURL as appropriate.

[Greg Neagle]

[QUOTE][u]Quote by: bw38[/u][p]Just to make sure I’m getting this right, I can add the general 10.6.7 combo update to my image, then add the 10.6.7 2011-MBP update into the image as well and this image would work on any Mac supporting Snow Leopard?[/p][/QUOTE]

I doubt it — if were that simple, Apple wouldn’t have released a separate update for the new MacBook Pros.

You’ll need two base images — one for Early 2011 MacBook Pros, and one for everything else. The one for Early 2011 MacBook Pros should probably be built from a Early 2011 MacBook Pro + the 10.6.7 update for the Early 2011 MBPs. The other one can be built from a retail release of Snow Leopard and then brought to either 10.6.6 or 10.6.7 via Combo Update.

[Author]

Posts