Usually mobile accounts are for portable computers IMO. So, I leave it off for iMacs and on for laptops.

In 1-to-1 situations we still set mobile accounts on, even for desktop Macs. Just to reduce the risk of failed logins.

Generally, non-mobile accounts should be sufficient though.

@davidacland

I haven't tried mobile accounts much, does it add a delay to the login?

@Poseiden951 Normally only on first login while the mobile home is setup.

Not from what I've seen. Assuming local home folders are being used, there shouldn't be a noticeable delay logging in with or without mobile accounts enabled.

I am unaware of a scenario where a mobile account would not be desired whether on a mobile computer or not. Setting it makes directory authentication more like Windows with cached credentials. Network connectivity is not always a given.

@powellbc I'll test it out later today and flip the switch on mobile accounts.

So for my AD BIND policy the User Experience TAB has

CREATE MOBILE ACCOUNT AT LOGIN 'CHECKED'
Require confirmation before creating a mobile account 'UNCHECKED'
FORCE LOCAL HOME DIRECTORY ON STARTUP DISK 'CHECKED'
Use UNC path from Active Directory to derive network home location 'UNCHECKED' not needed for us

both mac laptops and iMacs are being AD BOUND by this policy, so this has to be why the iMacs are also labeling user accounts as 'Managed Mobile'

would a separate AD BIND policy (with CREATE MOBILE ACCOUNT AT LOGIN 'unchecked') need to be made and used only by iMacs ?

@tcandela, that is a great question and I too would love to know this!

Just curious, but what exactly is the concern with having managed mobile accounts on an iMac? If you're getting hung up on the "mobile" label, you shouldn't. Its not just for laptops. It just means that the account is cached on disk, along with a password, so if for some reason the network is unavailable or someone unplugs their network cable form the back of their iMac, they will still be able to log in.
As @powellbc said above, I can't think of a reason not to use cached mobile AD accounts. I had once long ago used network only accounts on our desktops several jobs back and it wasn't the best experience. I see no reason to go back to that.
If there is some specific concern over this, I'm curious to hear what it is.

@tcandela If you want to not use mobile accounts on the iMacs, you would need a separate directory bind object.

Again, though, as @mm2270 and I are thinking, there is no scenario we know of where it would be beneficial to not use mobile accounts.

I was under the assumption that laptops bound to AD would have user account labeled as 'managed mobile' while the iMacs (staying put on office desks) would have user accounts labeled just as 'managed'.

@mm2270 you're right, I am/was just getting caught up on the 'MOBILE' label - kinda strange to see 'managed mobile' for user accounts on an iMac. But i fully understand what you're saying and agree with you and @powellbc , and will leave it as is (laptops/imacs with user accounts at 'managed mobile')

@Poseiden951 - looks like a separate AD BIND policy would need to be created to separate mobile accounts on laptop vs iMac.

my question, more a curiosity has been answered. thanks

The only situation that I've run into that mobile accounts were not desired were in our labs because of how we do user cleanup, or how we did rather. If you use mobile accounts additional files are stored on the Mac for DSCL. We would typically just blow away the users's home directory and life was good, but if you just delete the home directory of a user that's a mobile account without also deleting their DSCL plist file (in /private/var/db/dslocal/nodes/Default/users/), the next time the user logs in their user environment is totally hosed up.

Not a big deal for fixed labs, right? We just went back to a non-mobile AD bind for labs, but what about my laptop checkout pool? That's not gonna work, and they wanted a solution to turn around the laptops when they are returned that was quick, that didn't involve a whole reimage, which also wears down drives. Might be different these days with SSD.

I wrote the following script to deal with this process using the jamf binary instead since it cleans up user accounts properly. They run maintenance as a self service item so they don't necessarily need admin. This script is run as part of a startupitem that's copied to the proper location when invoked and then the machine reboots, runs the script, cleans up users, and then deletes the startup item.

#!/bin/sh



    ## Checking for valid Internet connection for maintenance"

    /usr/sbin/jamf checkJSSConnection



    ## Ensure this computer has a valid computer name file

    if [ -f /private/var/computername.conf ]; then



        ## Make sure this computer is suppose to run maintenance based on machine name in file

        if /usr/bin/egrep 'MAC-LPCO-|mac-lpco-|MAC-CJCART-|mac-cjcart-' '/private/var/computername.conf'; then



                ## cleanup any leftover admin directories from packages

        /bin/rm -rf /Users/admin/



        for username in `ls /Volumes/Macintosh HD/Users/ | grep -v Shared`

        do

            /usr/sbin/jamf deleteAccount -username $username -deleteHomeDirectory

        done



        fi

    fi



    ## Even if the machine name doesn't match be sure to prevent from running again by deleting the StartupItem

    /bin/rm -rf /System/Library/StartupItems/LPCOMaint/

thanks

Also don't forget that a mobile account is required if you need to use FileVault.