User Environment for group of users

Hi Nathaniel-

This seems to be an interesting situation. This might not be the best (or supported) approach, but I can tell you how I would approach it.

What I would do is make a generic, custom user home directory into a package a la Composer. Don't just grab the changes though, grab to whole 'example' user directory. Then make a policy like you normally would limiting the scope to the AD group you want and have it run a script with the following, for example:

#!/bin/bash

$USER=$3

# This next one may take some modification depending on how you connect to AD
$USERHOME=`dscl localhost read /Active Directory/All Domains/Users/ $USER NFSHomeDirectory | cut -d' ' -f2`

# Remove an existing home directory
rm -rf $USERHOME

# Mount package and copy contents (similar to how Casper works)
mkdir /tmp/packages
mount_afp afp://user:password@server/share /tmp/packages # For us it's "mount_afp afp://user:password@xsrv1/CasperShare /tmp/packages"

# Mount (or "attach") the package
hdiutil attach /tmp/packages/Packages/<package name>.dmg

# ditto out the contents into the user's home directory
ditto /Volumes/<package name> $USERHOME
# Change ownership
chown -R $USER $USERHOME

# Cleanup
hdiutil detach /Volumes/<package name>
umount /tmp/packages

exit 0

This script will obviously have to be modified to match your infrastructure, but will mount the package and copy the contents to the user's home directory. If this policy only runs for the users in a certain AD group (via the policy scope) then you should have the solution that I think you are looking for.

This method of mounting the package and using ditto is what Casper used to use for package installation and is currently used as the fallback if asr (the current copy method) fails. Unfortunately, I don't have the experience with ASR to show you how to use that.

I cannot stress enough that I just typed this script into this email. It is not something that I use in practice and it's possible that there might be errors is it so make sure you test it before you use it (should be good practice for anything you use).

Hope it helps, let me know if I can help any further.

Ryan Harter
UW - Stevens Point
Workstation Developer
715.346.2716
Ryan.Harter at uwsp.edu

Hi Nathaniel,

Can you clarify the language here a bit for me...particularly the per user stuff.

Do you have additional settings that need to get applied to just these users (and not anyone who applies this particular package), AND a unique dock you want for these users as well?

Craig E

Craig,

Sorry, I'm not clear myself in some ways. when a user from an AD group called "online testers" logs in to a computer I want a policy activated by that login to set the desktop, dock, system settings and install the test application software package. The dock will be empty except for that one test application, some finder prefs (don't show connected servers" and a different background desktop to show that it isn't a standard user. So the Application package isn't unique to the user but the Dock and such are unique to the user who is a member of this group. I don't want this online testing User Environment settings to be applied to other users on the computer or the User template on the computer. Just these few testing users who will get local home directories made on the computer when they login-per the AD plugin settings.
Does that help?
-Nathaniel

I get it now, it didn't click before.

You want the User Environment stuff to only apply to that user. I'm not certain there is a method to do that with the options in the JSS right now, which is why you are asking I assume. It's either apply the settings to the template, all existing user profiles, or both, and NOT just the user that logged on to trigger the policy. The dock isn't an issue of course.

Not sure how it would work, but the only options I can think of are to actually package up the preferences in a package that has folders and files for /Users/testing1/ so it really only does apply to those user accounts. Of course a single login would be best, but you may need multiples of course. Otherwise some scripting to copy files to a particularly logged on user would work as well. At least with anything run through the local binary it's easy to call the logged on user. Not sure if settings for background and finder when just applied with a file copy work unless Finder is restarted?

Smarter minds might have some better options. Workgroup manger comes to mind, and I don't use that at all so I won't be helpful, and it's not helpful unless you use it as well. More and more little things have been coming up to lead me back to having that second set of configuration tools available with JAMF's.

Am I helping, or not?

Craig E