_mbsetupuser is a real pain

There definitely is, but depending on how many policies you have, you may not like it.

I avoid this by setting an Exclusion in the Scope of the policy to exclude a local user, and put that user plus the "adobeinstall" user in the Exclusions list.

+1 @pmcgurn - I see that as the best way to go.

Often, when I upgrade OS X on a Mac server remotely, the _mbsetupuser kicks in after reboot, and it screws up Apple Remote Desktop. I have opened an SSH session, and tried to kill it, but it won't die. If anyone knows how to kill it, please let me know. Forcibly rebooting using "sudo shutdown -r now" usually stops this BS but I would love to not have to do it.

@howie_isaacks I forgot about the ARD issue. Another wrinkle in the _mbsetupuser existence is that it always asserts itself whenever a user logs in to the computer for the first time since the upgrade. So even if I use admin credentials to perform the upgrade process and the first login after the upgrade is the admin account, _mbsetupuser jumps in. And it seems to always stay present and "logged in" until the real user restarts the computer. Then when another user logs in to that computer for the first time, _mbsetupuser returns and stays logged in until restart. It's a horrible mechanism that seems to have no other purpose than display the "Login to iCloud" prompt.

@AVmcclint It's as if someone somewhere at Apple forgot that they made OS X Server that admins will want to control through ARD, and their obsession with trying to get us to login to iCloud over powers their common sense. I love iCloud on my personal Macs, but not on a server!

Looks like this is happening to macOS 10.12.4 installers and up. im having that issue now with DEP . Anything under 10.12.3 will not exhibit this issue. I created a post found here.....

https://www.jamf.com/jamf-nation/discussions/24237/dep-w-10-12-5-done-from-internet-recovery-account-creation-issue

Yes, the _mbsetuser is a real pain, in particular for any system that gets updated remotely via ARD or screen sharing. It appears to run plenty of configuration or migration processes. The only way to stop it is to reboot the node. I usually wait until all its processes stop consuming CPU, as most of them appear to never quit :( Then I reboot the Mac.

This is a problem for me because during DEP setup, I can't use the Administrator/admin name because policies are being triggered that we hve setup for the admin account. Once _mbsetupuser applies the policies, it wont let me create the Administrator/admin account.

You can run a while loop script until you see a user other than _mbsetupuser logged in:

#!/bin/bash

setup_user=`users | grep -c _mbsetupuser`

while [ "$setup_user" = "1" ]
    do  sleep 5
        setup_user=`users | grep -c _mbsetupuser`
done

loggedInUser=`users`

echo "The User Being Provisioned is $loggedInUser"

exit 0

Here's what I did to keep the _mbsetupuser from kicking in on my systems running macOS Server. I made a configuration profile that disables the Apple ID setup during login. This may not work in every situation, but it has kept my servers from going into the iCloud setup process after a major update. I know a lot of admins have moved on from running Apple's server app, but I still run it in a lot of environments that I manage, and it still works well. Apple claims that they listen to us when we submit feedback. I have given them feedback about this very thing several times. I guess they're not listening.