Please tell me we're going to be able to suppress these and a million notifications aren't the future for end users:

"Login items added" in Ventura

Try adding com.jamfsoftware.startupItem as a label or com.jamfsoftware as a label prefix.

That did the trick! Thanks!

We only have about 25 admins out of over 800 users so the possiblity is very small. I watch the hell out of them and tighten the rope when they get out of line, which doesn't happen often. We can lock a machine as a last resort for compliance which we have only done once in over two years.

I just want to point out that a non-admin may still be able to disable certain LaunchAgents critical to management (at least in my testing), just be sure to test toggle all items in your environment if it's a concern to you.

Also, thanks @A-bomb for your notification suppression config! I've decided to double down and employ it along with our login & background item management profile.

Thanks for the heads up. I admit not testing every one but will today. Glad you are having success with the suppression. I have been considering both as well.

I just want to point out that a non-admin may still be able to disable certain LaunchAgents critical to management (at least in my testing), just be sure to test toggle all items in your environment if it's a concern to you.

Also, thanks @A-bomb for your notification suppression config! I've decided to double down and employ it along with our login & background item management profile.

Only Jamf Software (2 items) can be toggled off without admin. Thank God. I am going to work on whitelisting those as detailed on this thread. Thanks again.

I've created the Service Management - Managed Login Items profile and uploaded to JAMF. On my test machine it works as far as locking the on/off sliders in login items, but the notifications still appear on every reboot. Am I missing something? I was under the impression that this profile would stop the notifications also?

Only Jamf Software (2 items) can be toggled off without admin. Thank God. I am going to work on whitelisting those as detailed on this thread. Thanks again.

No problem! Yeah, going out on a limb here, you might not want a standard user willy nilly disabling anything Jamf haha! 😉 fwiw, a couple I ran into were from Outset, Munki, and Zoom.

I've created the Service Management - Managed Login Items profile and uploaded to JAMF. On my test machine it works as far as locking the on/off sliders in login items, but the notifications still appear on every reboot. Am I missing something? I was under the impression that this profile would stop the notifications also?

This thread has two things going on. Locking them like you are referring to and suppressing notifications like I posted about with screenshots and schema. Can you post your XML and domain here?

I've created the Service Management - Managed Login Items profile and uploaded to JAMF. On my test machine it works as far as locking the on/off sliders in login items, but the notifications still appear on every reboot. Am I missing something? I was under the impression that this profile would stop the notifications also?

There are a few options for notification suppression. A-Bomb's is great for discrete suppression of notifications on apps. You can take a more nuclear approach and block com.apple.btmnotifications, which is the object that manages login item notifications: Background Task Management Notifications. You can also use the Notifications Preference Control and adjust to taste. For example:

Note that I'm not targeting this against any devices unless it becomes an issue. Generally speaking, I want users to be notified to make a choice when a login item is added; we're also enforcing a large amount of organizational apps, so for anything beyond our approved software I want users to be able to make that choice.

What I posted disables all of the new login and background items added notifications in Ventura. I don’t see the point of having those in our environment. What others have posted here is for specific login or background items. Application path is not recommended and never worked for us. Only using bundle ID did. It can be kind of a pain in the ass to get the bundle ID but once you get it and use it, you can forget about it..

Agreed, Bundle IDs are a nuisance. This is how I derive mine. You can either derive it from the app's Info.plist, using the commands below (location may vary, but should be in the *.app contents):

/usr/libexec/PlistBuddy -c 'print CFBundleIdentifier' /Applications/<application>.app/Contents/Info.plist

or, sometimes in the codesign output, where you can also find the TeamIdentifier:

codesign -dr - /path/to/Application.app

Example:

(Commands in green, BundleIDs in yellow, TeamIdentifiers in red)

My current process order looks like this:

Profile Creation

Create and install a Jamf self-signed certificate: https://docs.jamf.com/technical-articles/Creating_a_Signing_Certificate_Using_Jamf_[…]CA_to_Use_for_Signing_Configuration_Profiles_and_Packages.html
1. Note: It's necessary to sign the configuration profile that you create because Jamf 10.41 does not yet have a a Policy item for com.apple.servicemanagement. Uploading a signed configuration profile pushes out valid configuration items, but Jamf is basically just being used as a dumb push service at this point, because it can't interpret that item properly
Download and install iMazing Profile Editor
Upload sample configs into iMazing Profile Editor or craft your own using the Service Management - Managed Login Item
iMazing Profile Editor config profile creation

codesign -dr - /path/to/Application.app/usr/libexec/PlistBuddy -c 'print CFBundleIdentifier' /Applications/FortiClient.app/Contents/Info.plist

5. Upload the configuration into Jamf

I'm scoping my configuration profile to all macOS Ventura machines. If you scope to current machines it gets installed (if you were wanting to preload), however the profile won't reload its settings when the Ventura install completes and you won't see the benefits of the config.

Instead, consider installing the config between the time a device updates from macOS 11/12 to macOS 13, and when a user logs in. To accomplish this, I created a policy that runs Inventory at startup on all devices.

This is great. Can you post your code here? I can't get this to work.

So been making good progress in preventing users from disabling login items but I got one that still tricky. Looks like in Ventura there is a "StartupScript.sh" located in the /Library/Application Support/JAMF/ManagementFrameworkScripts/ folder. Seems like a simple script to ensure everything is working. So would rather not have the user disable it as login item. Anyone have success in doing that?

Btw, iMazing Profile Editor rocks!

This is great. Can you post your code here? I can't get this to work.

I've created the Service Management - Managed Login Items profile and uploaded to JAMF. On my test machine it works as far as locking the on/off sliders in login items, but the notifications still appear on every reboot. Am I missing something? I was under the impression that this profile would stop the notifications also?

Can you post your code here? I can't get this to work.

This is great. Can you post your code here? I can't get this to work.

You're looking for my launch agent enforcement code, specifically? I think it's under NDA, but if you're on Slack I can send you a copy?

That would be sweet @A-bomb

You're looking for my launch agent enforcement code, specifically? I think it's under NDA, but if you're on Slack I can send you a copy?

Look at this beauty. Thanks again for your help @Baravis

Do you find that the notifications for these background items suppress also?

I do find that, yes. Supposedly I should be seeing a “your organization is managing login items” pop-up, also, but I’ve yet to see that either.

Do you find that the notifications for these background items suppress also?

I just did some testing on my MBA M1 running macOS 13 b11. Approving Login/Background Items does not suppress the notifications. Two separate Configuration Profiles are needed to achieve both. I was able to repeat this a few times too. I haven't seen “your organization is managing login items” either.

I’ll have to recheck my Apple Silicon test unit then, thanks for the heads up!

Hmmm. I thought that was how it functioned in the beginning. Maybe a bug in the beta. What are you deploying for the notifications?

At present, nothing. Notifications haven’t been popping up in my tests with the login item enforcement configuration profile in place. I have to double check my tests, but I’ve been seeing 0 notifications on my Intel device.

They weren't popping up but rather sitting in Notification Center. When I applied the allow profile we worked on yesterday they stayed in there but when I applied the notification mute I posted here they immediately disappeared.

I've noticed that when the Login Items are locked to the user via a config profile if they are an admin they are able to turn items off with an entry of their password upon selection. Seeing this on public beta #22A537b. This is just as bad as not locking the item off. Does anyone else see this and perhaps have a solution?

This solves it...

Baravis
My current process order looks like this:
Profile Creation

I've noticed that when the Login Items are locked to the user via a config profile if they are an admin they are able to turn items off with an entry of their password upon selection. Seeing this on public beta #22A537b. This is just as bad as not locking the item off. Does anyone else see this and perhaps have a solution?

@jbutler47 This is not my experience. With the profile in place nothing can be toggled on/off, admin or not. If you can toggle ALL items as admin, I suspect your profile isn't properly signed. If it's just a few, you might need to check your xml formatting or maybe try an alternative RuleType for those items.

Reply

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded