OSX DEP Prestage Enrollment... Assigning / Grouping machines..... Best Practices

@fedagain since we are limited to what information we can set in the PreStage Enrollments to help with this, I use a Department named DEP to identify machines that have been enrolled via DEP. Then I have "First Boot" policy that is scoped to machines in that department. So using a field on the "User and Location" tab or the Purchasing tab to scope with would probably work. Of course, to make it simple, I would stick to those fields that the JSS natively sees in the Scope tab of a policy, that way you're not having to rely on a recon for that machine to drop into a Smart Group.

If you need different machines to get different policies, you'll most likely need separate PreStage Enrollments for each "class" of machine.

Hope that makes sense.

@stevewood If I go the route of having the mulitple PreStage Enrollments....

a.) How do you get the correct machines into the correct Enrollments? Is there a place in DEP or do I pool them all into JSS and then separate them? That sounds like unnecessary work, eh?

b.) After the above (a) is accomplished I could use smart groups to find machines that fall into PreStage Enrollments, but as you stated, that might need a Recon to update them, or since I WOULDN'T be using an EA, it should work without the Recon to drop them in the Smart Group?

Thanks for you help so far!

I think I answered my own question regarding a.)

I would just select the ones I want in each PreStage.

Sorry, I didn't have any machines in there to test with, so it didn't dawn on me right away.

Okay, I think I got this now........

Put the proper machines in each PreStage, find the machines via Smart Group and Scope the polices to them that way?

That sounds like a good workflow, yes?

@fedagain Yes, that's how I would handle it. Again, if your using fields that are already in the JSS (Buildings & Departments), I'm not certain that a recon would be necessary. And if not necessary, those two can be scoped against so that you are not having to wait for a device to pop into the right Smart Group to get the policies scoped to it.

I'm running on 9.82 right now, and for me there is a little bit of a lag (less than a minute or two) between seeing the desktop and the "on enrollment" policy that I use for DEP machines to kick off. So I finish Setup Assistant, the user's desktop loads, and then within 2 minutes the policy kicks off to finish loading everything and then restart the computer.

@stevewood How are you handling the initial login, manually? If auto, how? AND Also, how are you having them restart and how do the machines know when to restart?

Hope that makes sense!

@stevewood How about automating as much of the process as possible when working with DEP comps out of the box?

Skipping setup stuff and auto login to the local admin account?

@fedagain I haven't tested with 9.9x versions of the JSS, so they may handle this different (I thought I heard they would with El Cap), but out of the box machines, or machines that have a fresh OS, run through Setup Assistant and have you enter a first user and password. The machine then finishes Setup Assistant and lands at the desktop of that first user you create during Setup Assistant. At that point the JSS receives the "Enrollment Complete" acknowledgment and starts whatever policies are set to trigger on that.

My understanding is that with El Cap and 9.9x versions of JSS, that once you get to the point in Setup Assistant where you are informed there is a configuration waiting, the system completes Setup Assistant without asking for a "first user" and password. Again, I could be way off on this as I have not tested it myself yet.

My current method is to use the same user and password for the Setup Assistant part. Then, the policy that kicks off after Setup Assistant downloads @jtratta [Enrollment Screen] (https://jamfnation.jamfsoftware.com/discussion.html?id=17467#respond) and then runs a script that is hosted in the JSS. The script handles any configuration things (setting NTP, disabling .DS_Store, things like that), installs all base software via jamf policy -id calls (these policies are scoped to machines with "NEW-" as the first part of the name), deletes that first user that was created during Setup Assistant, runs softwareupdate -ia and then finally restarts the computer with shutdown -r now.

I basically just run through Setup Assistant and then let the system sit until it is back at the login screen.

Hope that answers your questions. I'm happy to expand more if you need.

@stevewood I'm using 9.91 and the process is the same as your describing you currently do, so I don't think it's changed in 9.91 or maybe I'm missing something. I JUST came off of JumpStart so I'm a newbie and still have a LOT to learn... haha.

I appreciate your time!

Totally different question regarding policies (Install, Cache, Install Cache)..... When is best to use the different types? I have Adobe CC Split into separate installers for each app, and I have them set to install.... is that okay?

@fedagain The different install methods you mention really depend on how you want to deploy and how solid your infrastructure is. Large packages or policies, say the main three Adobe CC apps (PS, Ill, InD, plus Bridge), I would typically cache those with one policy and then install with a second policy if I am pushing to an end user. Reason being that the user only has to wait for the installation of the apps to finish and not the copy from the server AND the installation. Make sense? Something like an Adobe update (moving from CC 2014 to CC 2015 for example), I would cache the installers and then use a policy triggered on logout (or perhaps a Self Service policy) to do the actual install.

During imaging I use straight install triggers, no caching first.

One of the main reasons to cache first is to alleviate the wait time the user has to endure for that installation to finish. At least that's how I see it.

Makes sense and that is basically how I visioned it also. Good tips!

Thank you!

@stevewood Hey Steve, I have a question regarding something you mentioned above.....

"My current method is to use the same user and password for the Setup Assistant part."

What do you mean by that exactly? I'm not getting all the features your mentioning, in particular, the restart at the end?

My imaging consists of out of the box (DEP), go thru the setup screens, login (logging in with the same account I use in JSS), and then JSS pushed all the policies to the machine. That's it.....

Please advise.

Thank you!
Dave

@fedagain Sorry, I should have been clear. Being lazy about it, whenever I run through DEP I use the same user and password to go through Setup Assistant. So, when Setup Assistant asks to setup the user, I use MyUser and MyPass (no that's not really it) for that part. Then, in the script that runs I have a section that uses dscl to delete MyUser. Does that make sense? The proper way to do it would be to walk through a dscl output and look for the 501 user and delete that user. That way anyone could put in whatever they want and that user would get deleted.

When I've walked through DEP, I go through the Setup Assistant screens and once I finish with that, the machine is already logged in and at the user's desktop (the user that was setup in Setup Assistant). Make sense?

From that point, the policy that is triggered to "Enrollment Complete" kicks off.

@stevewood Hey Steve..... I'm logging into the prompted username and pwd (after Location Services screen I'm prompted to login, to a JSS account or AD account) with the same credentials as one of my JSS admin accounts. In JSS I have the settings set for a local user admin account to be created. Does this sound okay / normal?

My interest is in the Auto login to the local admin user account that JSS is setting up, but it sounds like your using the setup assistant to create a local account and then purging that account, correct? Is this a better method than using JSS to create the local account? Are you using a pkg to create a local admin user in your policies?

My other snafu is how your using a script to trigger the restart when it's all complete, how does it know when it's all finished? I could see how this being easy if using a Conguration, but how does JSS know it's completed all the other installs and then run the script to restart?

@fedagain that, I believe, is the difference in pre-9.9x versions of the JSS. In my version, 9.82, I do not get prompted to login as an AD account or to a JSS account. I am instead prompted to create a user on the Mac, just like I would if the machine were not managed. There was a change in the DEP spec by Apple in 10.11 that the JSS did not take advantage of until 9.9.

I'm in the process of upgrading my dev JSS to 9.92 so I can do some testing of this. As I mentioned above, the local account is being created as part of the Setup Assistant, and to make sure it is not left on the system, I purge it with my script. I would prefer what you are seeing, that the account is a JSS account. The JSS admin account is created as part of the enrollment. This is set under the "User Initiated Enrollment" settings under Global Management.

So, I do not use a configuration to install apps, etc. I instead use a policy that has a script in it. The script handles everything, including installing any software. You can see the script here on my GitHub: FirstBoot DEP.

Hope that helps explain things.