Need Help creating package using composer

Hi William,

Wow, this is going to be a real issue for us since we're trying to standardize our workflow (using Casper to deploy stuff to one location and aliasing to every user's Desktop).

I would have hoped that the DMG options tab should work with directory based environments to deploy stuff to all users (including User Template).

Has this been submitted as a bug to JAMF? If not, I'm happy to. :)

Don

That's odd. We're also AD-based but we don't see that behavior.

j
-- Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

To the best of my knowledge, this issue hasn't been addressed in any later
On 9/7/10 2:29 PM, "Don Montalvo" <donmontalvo at gmail.com> wrote:
version of Casper and the impression I received from JAMF was that they
don't consider this as a bug. It's the way the feature is now designed to
work. However, the whole FEU feature is pretty useless in
directory-enabled environments where mobile accounts are not used on
Desktops.

I've brought it to JAMF's attention at least a couple of times over the
past couple of years. Please send your "me too" to JAMF if you'd like to
see this behavior changed.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

That should work in most environments, however, it won't work in
On 9/7/10 11:50 AM, "Don Montalvo" <donmontalvo at gmail.com> wrote:
directory-based environments. We use Active Directory.

Casper's method for "Fill Existing Users" uses dscl to determine users
instead of simply looking in the /Users folder and in a directory-based
environment it will only return the current user. Grrrr.

I've had to resort to .pkg files with scripts to work around this issue,
which use to work before they switched to dscl back around Casper 5.0 or
6.0.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

Yeah I'm AD based and feel the same, makes life much more difficult

Sent from my iPad

I got a response from JAMF (thanks Miles!) confirming that as long as you have Mobile Accounts enabled (we do), FEU and FUT should both work.

<whew!>

Don

But not for the rest of us

I usually scour the release notes when new versions of Casper are released
On 9/7/10 2:32 PM, "Nichols, Jared - 1170 - MITLL" <jared.nichols at ll.mit.edu> wrote:
and maybe I've missed them addressing this issue. It's simple enough to
test:

1. On an AD-bound Mac with at least two existing home folders, "User A"
   and "User B", create a policy to install something to the Desktops and set
   the policy to Fill Existing Users (FEU). The accounts cannot be mobile
   accounts.

2. Log in as "User A" and you should see the item appear on the Desktop.

3. Log in as "User B" and you will not see the item appear on the Desktop.

I just did my due diligence to test and I'm finding this is still the case
for me.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

In this scenario, I'm assuming user a was logged in at the time the package was deployed.

If a user does not have a local home folder, or uses filevault, that user must be logged in at the time the package is deployed in order to benefit from FEU.

I hope this helps.

Miles Leacy
JAMF Software

--
Sent from my iPhone.

Right, those should work. However, we don't enable Mobile Accounts on our
On 9/7/10 3:05 PM, "Don Montalvo" <donmontalvo at gmail.com> wrote:
desktops. We don't want someone taking a desktop out of the building and
being able to log in. Just another layer in the onion...

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

Yes, User A triggers the policy. I neglected to say the policy should run
On 9/7/10 3:41 PM, "Miles Leacy" <miles.leacy at jamfsoftware.com> wrote:
at login.

Since User A is logged in when the policy runs then he will get the
software.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

Ok, so separating your user data into its own package and deploying the user data package at login, once per user, should get the data into each user's home folder.

Make sense?

--
Sent from my iPhone.
Please forgive any typos.

That doesn't work when users need to log in to multiple machines. Casper
On 9/7/10 4:08 PM, "Miles Leacy" <miles.leacy at jamfsoftware.com> wrote:
doesn't have a "once per user per machine" option.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

If they don't have local homes, the machine is irrelevant.

If they do have local homes than feu once per computer will get them.

Make sense?

--
Sent from my iPhone.
Please forgive any typos.

Sorry if I sound like I'm making excuses but this is our environment:
On 9/7/10 5:15 PM, "Miles Leacy" <miles.leacy at jamfsoftware.com> wrote:

Users log in with an AD account Users do not have network home folders A user can use multiple machines A machine is shared by multiple users

The way FEU is currently designed to work does not work for us.

What's irritating about this feature is that I took great advantage of it
before the change to using dscl to determine home folders. To me, it's a
feature that was taken away. I work around it with scripts.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492

William,

No worries. Sorry for the short replies yesterday, I was in transit but
wanted to offer some info.

I think we can still get you where you need to be with built in functions if
you install your user data containing package with both of the Fill Existing
Users (FEU) and Fill User Template (FUT) options turned on.

In the scenario you described, FEU will get the data to any user that has
already logged in to the computer and therefore already has a local home.
FUT will ensure that a user who logs in to the computer for the first time
after the package has been deployed will also receive the user data when
their home folder is generated by the system.

If you're seeing different behavior, please let me know off list and we'll
figure out what's happening.

Thanks,

-- Miles Leacy
Technical Training Manager
Mobile +1 347 277 7321

miles at jamfsoftware.com
....................................................................
JAMF Software
1011 Washington Ave. S
Suite 350
Minneapolis, MN 55415
....................................................................
Office: (612) 605-6625
Facsimile: (612) 332-9054
....................................................................
US Support: (612) 216-1296
UK Support +44.(0)20.3002.3907
AU Support +61.(0)2.8014.7469
....................................................................
http://www.jamfsoftware.com

I actually feature requested "once per user per machine" at the London CCNA which miles ran...

Ben Toms
IT Support Analyst GREY Group
The Johnson Building, 77 Hatton Garden, London, EC1N 8JS
T: +44 (0) 20-3037-3819 Main: +44 (0) 20 3037 3000 | IT Helpdesk: +44 (0) 20 3037 3883

Hi Vinay!
On 9/9/10 6:10 AM, "vinay washimkar" <vinaywashimkar at hotmail.com> wrote:

Be very careful of UPPER and lower case when using the command line.
Folder and file names must be exactly the same.

'Users' does not equal 'users"

This command first requires that the 'example.app' application be
installed otherwise it won't have anything to link to. Also, if you decide
to test this from the command line yourself then you must be an admin and
you must use the 'sudo' command before it.

For example, if your 'test' account is just a Standard account and not an
admin then you will need to first enter the 'switch user' command in the
Terminal:

su admin-name-here

You will be prompted for a password for that admin account.

Then you will need to run the same command with 'super user do' command
before it:

sudo ln -s /Users/Shared/example.app /Users/*/Desktop/

You will be prompted for a password again for the admin account. You
should see the link appear on the Desktop.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492