BYOD with Macs

We do not have a dual environment with BYOD and Company owned, But, if we did, i'd reconfigure my environment to scope all of the company policies and configs to all devices that are enrolled to a smart group scoped to all devices that were in enrolled under enrollment type: prestage enrollment. Then scope a separate set of configs for all other devices that are User initiated enrollment. that way the BYOD macs only get what you want them to get at enrollment. I'm sure other that are supporting this will chime in but that's how i'd handle it.... i think.

Apple does not support a concept of BYOD for Macs like they do with iOS, therefore Jamf does not. That doesn't stop you from allowing though, you just need a way to identify which are BYOD and which belong to your school.

Like @LovelessinSEA said, if all your school devices are in DEP, then that should make it easier and you can scope things accordingly.

Personally, I would question why you need them enrolled in the first place. Could you not get that wealth of web content posted somewhere else? If these are K-12 students, they might be using their parents work computers for school work, which might be enrolled in an MDM already.

Thank you @LovelessinSEA and @patgmac for your ideas here. Primarily, I was worried about the students, higher ed, to be able to get access to our self service application which has a lot of help pages. Granted, these could be made available using a single web page online. I found this site on BYO Mac.. There is some good information there as well. Just not sure how far this can go. I feel like Alice and the rabbit hole here could be rather dark and create a lot more work.

Hi @mconners,
It may also be helpful to set up Sites.

OK, wow! First, JAMF works great for BYOD environments. Supporting that type of environment was specifically the reason we moved to it in 2012. We are a private, international boarding (well, not at the moment) Secondary School in NH. We have several hundred Academy owned DEP (and some older non-DEP) macs +devices, and support about 360 student BYOD devices. It's honestly the very best way to manage such a thing. I'm not sure why the sentiments here sound otherwise!

Perhaps you'd like to talk to me offline over the phone or something. Feel free to email me chafner@brewsteracademy.org. However, in basic we onboard student BYOD devices AND DEP devices with the same policies run through DEPNotify. While the enrollments are different (DEP vs User Approved MDM) the GUI process is identical. Also, it makes managing the policies very simple.

The difference is mostly that 1, you don't own the machines and cannot utilize any feature that requires DEP and that 2, you need to have an offboarding process for BYOD so that your stuff leaves when the student does.

Anyways, I'd be happy to give whatever specific answers you want here, but again, feel free to email me and we can chat. This is what JAMF does and was founded to do! iOS has a lot of things developed form Apple, and JAMF supports those, but JAMF was built to manage the Mac. If I believed for one second that they weren't the #1 choice for that I wouldn't be here!

Thank you @Chris_Hafner for your thoughts on this. Your offer to talk offline is very much appreciated. I have a handle on concepts and an outline of what I want to accomplish. @shaquir you mentioned sites. I have begun looking into sites for this too. The question about sites though is, I don't see a way to scope any policy or profile via sites. My thought was, if I had a profile, let's say the Microsoft Office updater profile scoped to our existing site, which is nothing, I would replicate this profile and have the copy setup in the new site I create so there are two versions? Just trying to get my head around it. Do I create a smart group based on sites and use that for scoping?

Thank you again!

@mconners Site's usage is generally designed for you to either load balance between two very physically different locations, or where departments within a specific location have specifically different needs and probably, different admins and managers. Possibly, both. I don't see how sites will help you from the little I understand about your circumstance. Further, I think that using "sites" may add a huge complication to your environment unless you KNOW the need for using it.

If you want to split profiles between BYOD and DEP units, create a profile for each, and scope to the groups. I use "departments" as a scope for this kind of stuff, but you could do LOTs of things. LDAP groups, User groups, heck, you could separate based on enrollment type.

Sorry, I'm just looking at the path being talked about here and it looks like a lot of extra work in a weird direction. I'm not trying to downplay advice here, but I don't think it's suited to what you're trying to accomplish.

Thanks @Chris_Hafner I appreciate your insights into the matter. What got me thinking about sites is, when someone does a user initiated enrollment via a browser, they are offered a choice of what site to belong to. If we have our standard college owned devices site and another for personally owned computers, the thought was, this would allow students or employees to choose the personally owned computers site. But outside of that, I couldn't find a reason to do sites or how to assist those that are located in a specific site. Like you said Chris, it could create a lot more complication.

Still thinking this through so I welcome any and all comments to keep my thoughts moving forward.

Have you seen projects like DEPNotify, SplashBuddy, Octory.io, etc?

To give you an idea of how BYOD students on-board with us:

The student visits our enrollment site (yourJAMF.jamfcloud.com:8443/enroll or whatever) and logs in using their credentials. They're asked to download and install a profile. Once they do so, our DEPNotify UI downloads and launches. The user enters their name, and chooses their department and building from a dropdown (Preset for primary student onboarding). At that point, the process begins installing policies that we've selected for the initial deployment of all machines. Other processes may occur depending on the department or building chosen in the UI. The process is represented to the user while this is all happening. At the end of the items, we've chosen to install the UI quits and the computer is either ready to go.

This process is also utilized for our DEP computers in a similar fashion. The primary difference being that it's initiated after the first user logs in after DEP. Additionally, our DEP computers require FV2, so the process will reboot the machine to finalize the process.

There are plenty of ways to roll this.