Block Messages and FaceTime Applications on Mac OS 10.11 Only at School

I can think of a "tinker toy" way to do this but it would be through the use of scripting and login hooks. I invite folks to chime in with a better way.

In your login script, you could move the executable to a non accessible to end user folder during the hours of 8 am to 4 pm (or whatever time is appropriate). If the user logs in after 4 pm, then put it back. You could probably save moving the app and just change permissions on the app bundle instead.

The downside to this is that it would require the user to log out and log back in after 4 pm.

If you had good script writers (like the kind folks on this board), you could get fancy and also account for if the user is hitting your domain controller or not.

Another thought involves creating 2 launchDaemons that set the correct permissions on these apps at the correct times. For this I would create a LaunchDaemon (keeping it alive every 30 min or so) that calls a script which checks the time and sets appropriate permissions for FaceTime/Messages accordingly.

Just a dumb thought looking at this at my lunch. I would have to write these up and test sometime (which I can't offer to do this week) but I believe you could accomplish in scripting and or LaunchDaemons.

Blackholemac

Quick question, is your JSS accessible from outside the school network (Limited Access JSS?) If so, you could look at getting a bunch of iBeacons and setting them up within the school. Upon seeing the iBeacon, a policy would move the computers into (or more likely out of) a group that could remove the Restricted Software setting, meaning move them out of scope for that particular Restricted Software.
When it sees they are no longer in range of the iBeacon(s), it would put them back into scope for the Restricted Software setting and it gets applied again.

A long while ago, I played around with a concept of changing Restricted Software settings based on timeframes, kind of like what @blackholemac mentioned, except it wasn't physically moving the application bundles, just changing the actual Restricted Software settings to enable a product for use within a certain timeframe and later disable it.

I'd have to dig up that process and dust it off to see if its still viable for a case like this.
Personally though, I think using something like Network State Change triggers or iBeacons to know if the Mac is within the school walls would make more sense, that way it could get enabled on days when school is closed (holidays, PD days, etc), not just within certain hours.

And all that being said, I'm almost sure there is a Feature Request out there asking for something like this to be a part of the Suite by default, so I'd locate that and vote it up if its important to you.

IBeacons could do this well too!

Hoping someone had more to add.

Hello @mm2270 , our JSS is accessible from outside the school network. I wish it wasn't in this case or this would be simple, haha! I agree definitely on the iBeacons. I have never used them before but I see where that would be a solution. Thanks @blackholemac on your ideas too, those probably would work also but I am leaning more to the iBeacon idea right now with you.

One question on iBeacons since I have never used them. In Restricted Software, could I scope it to the student group and limit it to being connected to the certain iBeacons? Or would I only be able to scope it to the certain iBeacons so staff and anyone besides student group members get these applications blocked also?

There has to be a different solution available than iBeacons. What if they don't want to purchase them?
Can you add the apps as a restricted application? Then you could set up the policy to run during school hours

Hi @CapU , I see what you are saying on the policy idea. I could do something like that with the ability to kill a process name. But keeping in killed without making that policy run nonstop would be the problem. That would let me limit it to only that building.

I really wish that the Restricted Software section would let you limit the scope like policies do. That would fix the issue.

@CapU If you mean JAMF must have another built in solution, the only real solutions, I think, are to use iBeacons or Network Segment ranges and a Network State Change trigger. The latter could also work, but there is the issue of preventing students from connecting to an external hotspot to get around the restriction. iBeacons, because they are local proximity beacons, can be more reliable, since its location based, not network based.

As for purchasing iBeacons, I see your point, although I believe you can get bulk low cost beacons for a reasonable amount these days.

@tomgideon2003 You can limit the scope of a Restricted Software item, you just can't "schedule" it. Its a local process controlled by the JAMF LaunchDaemon and a special xml file it uses to know which process(es) to check on and shut down.

To answer your question from before, Restricted Software doesn't have a Limitations tab, like Policies do, and where iBeacons normally show up. So you may have to get creative with this. At least I don't see an easy way to add in an iBeacon range as limiting factor for a Restricted Software title. (Running JSS 9.82 here still, so I can't say if this is true with more recent versions)

You could, perhaps, do this with a combination of a policy or policies using a Limitation of an iBeacon that writes a hidden file/plist for the Mac, then recons (submits inventory) and drops the Mac into a specific group or groups that would be in scope for the Restricted Software. This would need to be done with an Extension Attribute probably that picks up that value.
IOW, when the Mac is on the inside of the school walls and sees the iBeacon(s), it runs a policy that runs a script which writes or creates a hidden file, like /usr/local/bin/inrange or something. Then does an inventory collection (jamf recon) and a jamf manage command. You would have a Smart Group that uses whatever criteria you need, such as all Student Macs for example, PLUS the criteria of the EA script that picks up the existence of that hidden file. If its there, that Mac falls into said Smart Group that is scoped to the Restricted Software titles to block the Messages and FaceTime apps. The jamf manage command will pull down the scoped restrictions and apply them immediately.
Later, when the Mac goes out of range of the iBeacon, a policy sees that change, and runs a script to remove that hidden file, if its there, and again, does a jamf recon and jamf manage. Back in the JSS, that Mac would have now fallen out of scope for the Restricted Software due to no longer being in that Smart Group. The jamf manage command would pull down the Restricted Software settings again from the JSS and open up Messages and FaceTime.

I hope all that makes sense. Writing it out it all seems very complicated, but I think once set up, its not too terribly difficult. I keep feeling there must be a more direct way, but I'll be honest, I haven't used iBeacons either, because we don't have a need for them here. So all the above is "theory" for me since I can't effectively test any of this. Maybe someone can chime in and show a much more streamlined way of doing this without all the scripting, hidden files and Smart Groups/policies, etc.