com.apple.servicemanagement inconsistencies in macOS 13.2

[Kaltsas]

We are a Jamf Shop and Jamf (currently until our instance is updated to 10.43.1) does not have a native mechanism for managing com.apple.servicemanagement. Jamf deploys their own com.apple.servicemanagement payload to manage the Jamf apps however since the ability to manage Login Items was added to MDM we have been using a separate payload to manage our 3rd party login items.

This has been working fine until macOS 13.2. Now we are seeing very inconsistent behavior where our managed login items are no longer managed. When I look at the deployment guide it seems like com.apple.servicemanagement allows multiple payloads. e.g. "Duplicates allowed: True—more than one Managed Login Items (com.apple.servicemanagement, com.apple.loginitems.managed) payload can be delivered to a user." Up to macOS 13.2 the behavior was that multiple com.apple.servicemanagement payloads were respected. https://support.apple.com/guide/deployment/managed-login-items-payload-settings-dep07b92494/1/web/1....

I rolled back a device to 13.1 and this works as expected. ALL items both our and jamf's payloads are managed. This behavior is new to 13.2 in our experience. Additionally some (but not all) 3rd party login items seem to continuously (as in several times a day) prompt the user that $developer has added items that can run in the background. Citrix Workspace seems to be the most affected by this behavior. I'm not sure if this is because Workspace is doing background activities more frequently than other 3rd party applications. (I am not a developer but I imagine Workspace is doing more things more often than say Microsoft Auto Updater configured to check for updates every 12 hours) 

Has anyone else observed this behavior?

[sdagley]

@Kaltsas I haven't seen any problems with login items management when upgrading from macOS 13.1 to 13.2. Is there any possibility the scope of your Configuration Profile is excluding macOS 13.2?

[Kaltsas]

It is not consistent but I have been able to replicate in the office a few times. The behavior is like macOS decides to evaluate the first payload and stops (maybe once we're able to move to using Jamf native management of this payload it will go away). Of course when I'm trying to replicate it for my ACE case now I can't get a machine to behave this way. 

13.1

13.2 same payloads

[scottb]

I can test this today.  I need to update my test M1 to 13.2, so I'll note the login items before and after...

[sdagley]

@Kaltsas Try running the following command on a 13.1 and 13.2 system then compare the output to see if there are differences in the com.apple.servicemanagement payloads:

sudo profiles show -output stdout-xml

[Kaltsas]

sfltool resetbtm

Seems to resolve it. See link for details on sfltool.

https://support.apple.com/guide/deployment/manage-login-items-background-tasks-mac-depdca572563/web#...

[scottb]

FWIW, I just updated an M1 Mac from 13.1 to 13.2 (using a full installer) and my login items are as-was.
So, none of them here were impacted by the update...and I don't manage Google here due to some needing to have it off for dev reasons...

[Kaltsas]

Thanks for testing. I had enough reports of it and then was able to replicate it twice but by no means have all our 13.2 folks reported the behavior. I'm happy sfltool resetbtm seems to resolve. Such is complexities of modern macOS. I gather it's related to this behavior recently reported by MacRumors.

https://www.macrumors.com/2023/02/02/macos-background-items-added-notification-bug/

[scottb]

Yeah, could be.  This OS has been a challenge, to say the least!  But that's what makes JN and Slack (macadmins) so useful!  Couldn't do this job without them!