Mojave Workflow

ICT-JPC
New Contributor III

Morning,

I am after some help if possible. Further to my previous post (https://www.jamf.com/jamf-nation/discussions/31889/mojave-deployment-and-configuration-using-jamf-and-depnotify) we're a little further forward on how my organisation will be deploying Mojave. The workflow we have in mind requires some streamlining and, as a newbie to all this, I am wondering if anyone might be able to advise or assist with our process please.

Our Workflow is along the lines of:

> Utilising Twocanoes MDS we've decided upon repartitioning/formatting our drives, utilisting APFS and installing a clean Mojave - v10.14.5. This is kind of worked out now. This process is roughly: script to partition the drive, kick off the install script - this prompted to name the device, installs macOS and apply some basic customisations (location related, power settings, create local admin account)

> Where I am now is how to enrol the devices to JAMF. We have a mixture of DEP and non DEP devices, so I am wondering if we might be able to utilise a mixed approach of DEP enrollment and User initiated enrollment? However I am stumped how to do this.

For the manual/User initiated option - I understand that there is the jamf url, in that a user needs to logon to the computer, go to the url and the MDM downloaded/ran - it is this I an unsure about. Do I need to create a number of policies with JAMF, that are set to run on enrollment? If this is the case, as part of this process I need to bind AD - I have a number of Directory Bindings and policies created for these, but again do these just need to have the Trigger set 'Enrollment Complete' and if so, will they work themselves out, or might I need to create an addtional script/policy that systematically works through identifying the name of the device and picking it from maybe a list of the policies/possible OU's?

For the DEP devices - Is there a policy or something that I can create/run that will identify our DEP registered devices and in turn enrol them automatically? Again I am unsure about this side of things.

> Once the device is enrolled in JAMF and bound to AD I then need JAMF to apply various software installs. This needs to happen through a two pronged approach, in that there'll be a higher level, all devices smart group(?), where customisations needs to be made/applied to every device, regardless of location - along with things like AV, Printers. I then envisage a script or policy that will transfer the device, based on name, to a specfic smart group that will install all the relevant software packages for the specific location that it is in.

As above, any advice or input around the above would be most welcome.

Thank you.

5 REPLIES 5

PaulHazelden
Valued Contributor

I am heading towards a similar setup, but am waiting for our DEP to be sorted out so I dont have the answers for DEP.

I am thinking that you can use Recon to make a quick Add package, and with MDS you can drop the pkg onto the Macs and then run it with a script. This will enrol the Mac with Jamf. Should be no need to wonder if the user will do it or not.
I am guessing that the DEP experience will be the same as with the iPads, in that the DEP server pushes out the MDM server info and enrols the Mac.
We dont currently bind to AD so I cant answer that, I do know that you can push out a binding once the device is enrolled. For me setting enrolment complete as the trigger does work with policies etc.

For pushing out Apps etc to specific Macs after the basic enrolment stuff is done, I use Smart groups. Macs can be members of multiple groups at the same time. I have groups set up to pick up all Macs in one campus, and all Macs in another campus etc. You can simply send stuff to ALL clients, even if there is no group for them. I then have groups for Lab Macs, and even a pair of groups to pick up the teachers Mac in a lab and all of the student Macs. The Majority of my groups are done with the computer name as the criteria, we use Campus-room-MacNumber as our naming, and this makes it easy for us to break down the smart groups.

I have smart groups based on device name, which will pick up our Lab macs and apply policies to all of them the same.
I have some smart groups set as exceptions, so if a Mac is a member of a Lab but something is not done that needs to be completed first they will be picked up by the exception smart group and be excluded until they leave the exception group. An example of this in my 10.13 workflow, is as a mac is first imaged, the tech has to log in and accept the MDM profile before anything else can happen. I have a smart group looking for the MDM to be not accepted yet, and this is set as an exclusion in my policies. When the tech accepts the profile and the Jamf server becomes aware of this it will then start to drop the Apps.

As we use fixed IP addresses from DHCP on all of our Macs, and multiple VLANs across the college I can use IP address to pick up smart groups too. This is useful for me with our Laptops, I put them into a dynamic wired connection and can apply policies to them only if they are on that connection. And then when the user has them out on WiFi these policies do not run. If a MacBook goes to sleep on battery it will disconnect from the WiFi, not good if the Adobe package is halfway copied to the Mac. But on the wired connection it will continue to work.

I also am inclined to create smart groups, even if there will be only one device in there. If you un-enroll the device and have policies applied to it set by adding the computer not the group, the association will also drop. But if the policy is applied to the group then the association does not get dropped, and when the device is re-enrolled it will pick up its policies again.

I use the priorities in Jamf Admin to set up the order of when an app will be installed. From what I have seen all policies will drop apps of the same priority and then once they are all there ready to install it will do them alphabetically, and then go get the next priority of apps and do them all. Knowing this helps if you need to have something installed first and then follow that up. This does push the installation time scale up though as each Mac will install something and then on next heartbeat it will look for the next set to install, possibly adding in up to almost the full heartbeat time in between batches of installs.

Hope this makes sense to you and is of some help.

grecopj
Contributor

I've been testing MDS as well. I use a external HD or a USB stick to get a fresh copy of Mojave onto a machine when booting in recovery mode. I have Pre-Stage enrollments setup in JAMF to get the machine enrolled. I also have a different scenario with MDS to have it install a QuickAdd package if I don't want it to go the route of DEP.

With the DEP option, I also set up a smart group based on the Pre-Enrollement name. It then pulls down my policies and profiles for that machine group.

I would like to try the route of saving the MDS image to web server and installing that way. Just haven't gotten around to that yet.

ICT-JPC
New Contributor III

Hi,

Just to let you know we've now come up with a way of using MDS to deploy the OS, then we have to manully approve JAMF MDM, which then sorts everything else.

Thanks.

PaulHazelden
Valued Contributor

@ICT-JPC , I have a script that checks for that, and if it finds the MDM needs approving it will add the instructions to an instructions text document on the local admin desktop. Makes it easy for the Techs to know which ones need it doing on as we have some DEP and some not.

PaulHazelden
Valued Contributor

For our non DEP Macs, I am using MDS to push out a QuickAdd package. I have 2 versions of this with/without OSX 10.14 Install. Using a SMB file share to host the MDS files, I am getting around 30 mins to put 10.14 on a Mac, and then run my first run script. A DEP Mac installing from the recovery partition takes 20 mins to complete.
DEP Macs, MDS puts the new OSX on and does not need the quick add package.
I have a few Macs with no recovery partition, these I will have to work out how I get them sorted, it will probably be a manual install from a bootable stick.
My first run script puts a text file on the Administrators desktop, this has instructions for the Techs telling them to accept the MDM profile, and a couple of other housekeeping jobs as required. The script only puts the needed information there.