"Login items added" in Ventura

[PhillyPhoto]

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

[holger_netterby]

Hello, 
Sorry about the unclear answer here above :) 
I solved it by adding two more items in the com.apple.servicemanagement payload

Even if Microsoft is added as a TeamID in my profile that does not lock down some of their LaunchDaemons / Agents

Add a Rule Type with value Label and Rule Value of com.microsoft.dlp.install_monitor

Add another Label with Rule Value of com.microsoft.fresno.uninstall

If you have other binaries still unlocked press the information-i next to the lock-switch and you can find the binary used and look for the  LaunchDaemons / Agents using that binary (path to binary). When you found the correct Daemon or Agent copy the value for the key <key>Label</key> and put that in a new row in the profile. 

Hope that is more clear otherwise just write again.

(edit spelling)

[jkarpenske]

Thank you so much for the quick and thorough reply!  I'm going to try your method first thing tomorrow morning when I'm back in the office. 

[roiegat]

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!

[skeenan07]

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

[roiegat]

That did the trick!  Thanks!

[A-bomb]

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

[PablitoGordito]

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?

[A-bomb]

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?

[Baravis]

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.

[jonw]

Just to add to this & food for thought on the nuclear notification blocking approach vs. a focused blocking scheme.  Beyond giving end-users a choice, there's an obvious benefit to allowing this new security mechanism to do its job.  It's entirely possible for a standard user to install something (say DropBox from Self Service... or worse some random malware) that may only drop an agent into ~/Library/LaunchAgents.  If this is the case, it won't be visible from your admin account Sys prefs > General > Login Items.  Whether good or bad in your environment, something like this may go unchecked for some time, especially if there's no user warning.

[A-bomb]

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

[jbutler47]

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?

[A-bomb]

This solves it...

Baravis
My current process order looks like this:
Profile Creation

[jonw]

@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.

[Baravis]

Concurring with @jonw here, I haven’t been receiving notifications.  In some cases I used both a team identifier and a label prefix.

[jbutler47]

@jonw Thank you for reminding me to sign the profile. Works like a charm now. Going to test and verify again if the notifications appear during enrollment.  Let's just say that iMazing Profile Editor is a great help for this concern. 

[jbutler47]

Upon enrollment with the ServiceManagement profile, I do not see all the individual prompts for all the Login Items that were loaded, which is great.  However, there is just one, and perhaps an overall notification that states "Managed Login Items Added - Your organization added items that can run in the background. You can view these in Login Item Settings." This prompt has two options "Snooze for 1 Day" and "Snooze for 1 week".  I guess you could take or leave this prompt, but I'd prefer to not have it show up at all at enrollment, seems more like nudging the user to check. I do see the benefit for the end user to be prompted by "Background Items Added" if something else comes into play later on (as mentioned in an earlier post in this thread). Has anyone had any luck with suppressing the "Managed Login Items Added" notification without turning it completely off in case something else is installed later on? 

[roiegat]

I find that @Baravis's solution with the image in this thread did a great job.  No notification popped up at all for the login items during the build.  

[A-bomb]

Well, this is cool. Got this from Jamf this morning about the upcoming 10.42 release:

Configuration Profiles for Managed Login Items

Jamf Pro now includes two predefined configuration profiles containing Managed Login Items payloads, installed by default on eligible computers in System Settings > Privacy & Security > Profiles. These configuration profiles prevent end users from disabling certain background services of apps installed by Jamf in System Settings > General Settings > Login Items > Allow in the Background.

[jbutler47]

Looks like 10.42 will take care of Jamf and App Installer related items for Login Items, but the release notes indicate that you may still need to create or upload a config profile for other apps/services.  If I read that wrong, please correct me, but that is what it appears to say. 

[Baravis]

That looks correct, to me.  Jamf App Installers and Jamf software products are allowed by default.  Anything above and beyond that requires the use of a custom config for managed app installers (https://docs.jamf.com/technical-articles/Uploading_a_Configuration_Profile_for_Managed_Login_Items.h...)

[Fluffy]

For those less experienced in digging for Team Identifiers, Labels, etc., this page helped me out a lot:

https://hammen.medium.com/managing-login-items-for-macos-ventura-e78d627f88b6

[michael_madsen]

Is anyone else ending up with this notification instead?

[scottb]

Yep.  Just the one... 👍

[michael_madsen]

It's strange why Apple will post that notification. The user can't do anything about it anyway.

It can be closed with this applescript:

tell application "System Events"
	try
		set _groups to groups of UI element 1 of scroll area 1 of group 1 of window "Notification Center" of application process "NotificationCenter"
		repeat with _group in _groups
			set temp to value of static text 1 of _group
			log temp
			if temp contains "Managed Login Items Added" then
				perform (first action of _group where description is "Close")
			end if
		end repeat
	end try
end tell

[scottb]

Well, Apple is Apple, but users can do something if the items are not locked down...they can potentially turn them off/on unless admins lock them down.  I'm not sure Apple will totally remove all notifications as they are user-centric.

I don't mind that one as I have all mine locked down and notifications are off for all...

[michael_madsen]

Yes, it's just that as part of our enrollment process we install MS Teams (and a few other tools) and after we log user out (to activate FileVault) they login and land on desktop and this 1 weird notification sticks out.

It's not the end of the world, but it annoys me.

If the user at some later point installs some software and the notification is shown, I don't mind. It makes sense (maybe also for the user) that one action led to the other.

But in our enrollment scenario, this single notification stands out.

[scottb]

I get it.  I wish Apple would be user-centric, but when we're using Apple in the enterprise or EDU, let us manage them as we are tasked to do.  They still don't seem to get it, and likely never will.

They keep claiming Apple is Enterprise Centric, but alas, not so much.  

[michael_madsen]

Yeah, I'm still waiting for this to be fixed:
https://community.jamf.com/t5/jamf-pro/big-sur-laptops-skipping-account-creation-during-dep-enrollme...

[cbruce]

Hello Michael, How are you running applescript utilizing Jamf?  Thanks

[michael_madsen]

This is the script, I execute:

#!/bin/zsh

# get current user
currentUser=$(scutil <<< "show State:/Users/ConsoleUser" | awk '/Name :/ { print $3 }')

runAsUser() {
    if [[ $currentUser != "loginwindow" ]]; then
        uid=$(id -u "$currentUser")
        launchctl asuser $uid sudo -u $currentUser "$@"
    fi
}

removeNotification() {
    runAsUser osascript -e "tell application \"System Events\"
	try
		set _groups to groups of UI element 1 of scroll area 1 of group 1 of window \"Notification Center\" of application process \"NotificationCenter\"
		repeat with _group in _groups
			set temp to value of static text 1 of _group
			log temp
			if temp contains \"Managed Login Items Added\" then
				perform (first action of _group where description is \"Close\")
			end if
		end repeat
	end try
end tell"
}

removeNotification

You may need a Configuration Profile to allow this (I can't remember if this is the case).

[cbruce]

Thank you. You are correct regarding the Configuration Profile.  Requiring access to JamfManagementService.  Will work on getting that built, unless you have it handy.

[michael_madsen]

I believe these are what I have set up to allow Jamf to run these commands without asking user for permission:

 

 

[cbruce]

Thanks !  I utilized iMazing Profile and added Bundle Identifier com.jamf.management.Jamf. If that doesn't do it I will definitely utilize your detail.  Thanks again

[sdagley]

@michael_madsen & @PhillyPhoto You can suppress the Managed Login Items Added notifications by deploying a Configuration Profile with a Notifications payload for Bundle ID com.apple.btmnotificationagent setting Critical Alert and Notifications to Disabled (note that this will disable all Managed Login Items Added notifications, not just for items you may have locked via a Managed Login Items payload) :

[Shaun]

Is there any way whatsoever to block a notification like this for a .sh script? Presumably those don't have a Bundle ID (if they do I can't figure out how to find it) and this only applies to full blown .app applications?

[sdagley]

@Shaun Make sure the LaunchDaemon calling your .sh script has a Label entry in the .plist, and use that name in a Label rule in your Service Management - Managed Login Items payload.

[AVmcclint]

I have a similar situation. We have a LaunchDaemon that runs a shell script. I do have a Label in the plist. It is com.company.thingy. I used iMazing Profile Editor to create a config for all my other apps (I used sfltool dumpbtm to get the bundles for them) and they are all locked in but the launch daemon that shows up in Login Items as "sh" is not locked down. I have the entry in the profile as follows:

Label | com.company.thingy | generic comment 

I can't figure out why it isn't locked down when the signed profile is installed.  Is there something else I'm missing?

[AVmcclint]

Nevermind... I figured it out. I had text in the Team Identifier field. When I removed that extra text and re-applied the profile, it now works.

[A-bomb]

Well, that's cool. 10.43.1 converted my existing manual XML to the new Managed Login Items format, automatically. I was getting ready to rebuild it.