unable to create mobile account...

Active Directory bindings can be tricky depending on your environment. See if disabling the UNC home folder path setting helps. In our environment, that created all sorts of havoc before turning it off.

Hi.
Have a look here: https://jamfnation.jamfsoftware.com/discussion.html?id=5901

We ended up using a configuration profile for this that will create mobile account (without asking the user).
This is pushed to all clients and in the moment they log onto the machine it's creating the mobile account.

Works like charm and you can see that the profile has been pushed to/for the user.

Cheers

Thanks for the reply.

Unfortunately i've already tried that, without luck.

As i mentioned, it works when i use a machine which wasn't imaged with Casper, so i thought there must be an issue with the image, except i've now recreated the image - but no joy :(

anyone else had this issue?

I have this exact issue currently but am at a loss myself. Anyone ever fix this?

Is there already a folder in Users with the shortname of the account you're trying to create?

For the record, tuinte's question led to the correct answer for me. The user I was attempting to login with that was being denied with the message "Unable to create mobile account. There was a problem while creating or accessing..." had a folder for that user in the Users folder. I fixed the image and now that user is able to login successfully.

david.yenzer could you elaborate further what you did to fix the image. We are getting this and i am stumped. We use autodmg to create a dmg from the Apple installer file. I am not really sure what I could do to fix the image but your fix may help to give me an idea. What we have noticed so far is this issue happens with user folders that are larger than 20gb. New users are not a problem at all.

I'm blanking on what the original issue was here - this was awhile ago. It sounds like there was a network user on the master image that we made accidentally which prevented that network user from logging in after imaging. And to fix the issue we would have just deleted the network user the next time we remade the master image.

However, we don't operate that way anymore. We remade the image, but it isn't bound to Active Directory from the image. All excess/unessential users are not on the image. Then once a machine has been imaged we log in as local admin and run the QuickAdd package - which makes it talk to our server where it finds our policy that identifies machines not connected to AD and binds them. (It just works better that way because if the image is bound to AD then all machines imaged with it get imported into AD with the same name and for some reason don't work very well.)

I also have a policy that we've used previously to unbind and rebind machines - that is the long way of clearing up the "same AD object name" issue. A new binding is clean, we've just had issues in the past with the binding getting muddied up with the imaging process.

Note: We use external thunderbolt/usb drives to one-off image most of our machines now.

If any of those policies sound interesting, I'd be glad to pass them along. I didn't write them, so they're already out there somewhere else on JAMF thanks to the fine folks in the JAMF community.

For what it's worth - I'm seeing this too. The really bizarre thing is that after binding and logging in as an AD user, we get this error, but if I try logging in again (sometimes 3 times) it'll finally log in normally. Also, simply rebooting the machine and logging in again works without issue. It's pretty much driving me nuts! If the JAMF binary isn't on the machine (meaning it's not enrolled in Casper) I don't have this issue. I can use the same packages that Casper is pushing, manually bind the computer with the exact same settings that Casper uses, and don't see the issue. I've toyed with unloading the jamf daemon, but still have the issues.

Anybody else figure out what's causing this?