Home Forums Software InstaDMG User Account Settings and Composer Question…

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #379801
    tristan_mason
    Participant

    Hi All

    I am grabbing user account environment settings with Composer and am going to put them in my insta work flow but I have just a few questions.

    – I need to create the user account on the host machine with the user name I intend to use in the work flow yes?
    – Once captured, these settings will only apply to an account by the name i was logged in under?
    – I should put the settings in the workflow directly under the account creation pkg?

    eg:
    Create Admin Account.pkg
    – Desktop Image Setting for Admin Account.pkg
    – Dock Setting for Admin Account.pkg
    etc…

    – I can add multiple user accounts using this method in instaDMG?

    eg:
    Create Admin Account.pkg
    – Desktop Image Setting for Admin Account.pkg
    – Dock Setting for Admin Account.pkg
    Create Staff Account.pkg
    – Desktop Image Setting for Staff Account.pkg
    – Dock Setting for Staff Account.pkg
    etc…

    Am just trying to establish “best practice” as I go. Any tips greatly received.

    Thanks for the great assistance so far.

    Tristan

    #379803
    dead2sin
    Participant

    Best practice would be to set this stuff using a single firstboot package. You *could* do one package per setting, but I find it to be rather cumbersome. I generally do all my settings via a postflight script directly on the InstaDMG image except for those that can only be run on first boot, in which case I use a LaunchD item to run a script and then have it delete it launchd item and the script.

    Here is a running list of helpful stuff to change and the commands to do so:

    [url]http://osxdeployment.com/wiki/Firstboot_Postflight_Commands[/url]
    [url]http://osxdeployment.com/wiki/Firstboot_Script_Commands[/url]

    Some things like Dock I do with a package. I think customizing the admin login isn’t necessary…most things you admin should be done transparently using ARD, SSH, etc. This is the style of admining I came to adopt anyways, I’m sure many people do it many different ways 🙂

    Nate

    #379804
    tristan_mason
    Participant

    Hi Nate

    Thanks for the good oil. I’m generally not a script kinda guy but it seems as though this is a rather more elegant way to preform a setup rather than the one pkg per setting. I’ve just got a shiny new Mac Mini Snow Server and i’ll be having a look a using the Workgroup Manager for managed prefs too. So many options, so much to learn. It’s slow here at the office now that the school year has ended. Time for research…

    Regards

    Tristan

    #379805
    tristan_mason
    Participant

    The other consideration for me at present is that i’m learning as I go so i’ll use the one at a time approach, get it working well then look at the firstboot commands and learn that then try and integrate it.

    Tristan

    #379811
    dead2sin
    Participant

    If you have OD, I wouldn’t bother with any settings via package.

    The problem with multiple packages is that you’ll gunk up your receipts on the OS. Each package creates a receipt which you can view with the pkgutil command (pkgutil –pkgs). If it is payloadless, then there is nothing that pkgutil can uninstall, so the info is only somewhat useful.

    I don’t have OD right now, but if I did, most of my settings would go into OD and I’d ditch a lot fo the stuff I set via firstboot.

    Nate

    #379815
    tristan_mason
    Participant

    OD is another whole world for me to get into which I don’t have time for right now and I need to see how it would fit in with the rest of what we have and do here. The Mac OS kit is the smaller part of our operation although it is my domain to manage and I’m just trying to get the modular imaging working this break and leave the monolithic method behind so it’s kinda one step at a time. As I spend more time researching and building the more tools for management seem to present themselves. All good grist for the mill.

    I can see perhaps 2 strands developing here for my needs, perhaps one for the Labs which is set and forget. We use Deep Freeze so once it’s done other than an update (the main reason I went for modular imaging) we don’t need to touch it until next year/time it needs an overhaul. Staff could be managed by first boot or OD as they are a little more tied in to our systems as users and it may be a more flexible on demand way of delivering settings, updates and services to them.

    Just a thought.

    Regards

    Tristan

    #379822
    Rusty Myers
    Participant

    [QUOTE][u]Quote by: tristan_mason[/u][p]Hi All

    I am grabbing user account environment settings with Composer and am going to put them in my insta work flow but I have just a few questions.

    – I need to create the user account on the host machine with the user name I intend to use in the work flow yes?

    Yes. I think…
    Composer grabs the full path to the files and will install them in their appropriate spot on the machine you install to. I believe the Casper Suite from JAMF does the “heavy lifting” and installs them into all the users folders on a deployed machines. I don’t use it, can’t be sure.

    – Once captured, these settings will only apply to an account by the name i was logged in under?
    Yes. Assuming above is correct.

    – I should put the settings in the workflow directly under the account creation pkg?
    I think you should out the settings in the User Template folder. But that doesn’t answer your question…this is why.

    When you use the createUser.pkg, it doesn’t create the home folder. That happens when the user logs in for the first time. So, installing settings to a home folder that doesn’t exist creates an issue, I’ve seen it a few times. It causes LONG login delays for that account, sometimes as long as “screw this _hold power button_”. If you install the preferences to the User Template then all new users will get the preferences. OR you could package the entire home folder and deploy that. It’s probably going to contain a lot of cruft and really against the idea of InstaDMG, but it may work… I say may, because if the User ID is the same as the one you create, it may work. Test, test, test.

    eg:
    Create Admin Account.pkg
    – Desktop Image Setting for Admin Account.pkg
    – Dock Setting for Admin Account.pkg
    etc…

    – I can add multiple user accounts using this method in instaDMG?
    [/QUOTE]Yes, just duplicate the package and change the userdata. See issues above.
    [QUOTE]
    eg:
    Create Admin Account.pkg
    – Desktop Image Setting for Admin Account.pkg
    – Dock Setting for Admin Account.pkg
    Create Staff Account.pkg
    – Desktop Image Setting for Staff Account.pkg
    – Dock Setting for Staff Account.pkg
    etc…

    Am just trying to establish “best practice” as I go. Any tips greatly received.

    Thanks for the great assistance so far.

    Tristan[/p][/QUOTE]

    As others have said, your probably best with other methods to enforce policy. If you can manage with OD, thats what I would, and what I currently do.[quote]

    #379842
    tristan_mason
    Participant

    Thanks “thespider” for the useful reply. I’ve had an issue with account creation where it creates the account but not all the folders that should be inside it eg: the “public” and “sites” folder at best and all of them accept the “Library” folder at worst hence I was wondering if the order made any difference.

    Regards

    Tristan

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.

Comments are closed