I have a similar workflow and am seeing the same issue. I'm investigating.

I'm able to reproduce this behavior as well. I've filed a bug report with Apple and opened a ticket with Apple Enterprise support.

For those who want to duplicate the bug report, the bug ID is 20482382. I have it also posted here to OpenRadar:

http://www.openradar.me/20482382

Dittoing that the behavior is reproducible. Filed a duplicate ticket against rtrouton's.

Confirmed it here as well just now. Just frickin' great! We use a similar process for creating our AD mobile accounts. Good lord Apple! Can't they get any release out without major bugs these days? What is going on with them lately!?

Also confirmed this bug. Couldn't figure out why my known working script just didn't work in 10.10.3 hope a fix comes out soon or someone finds a workaround.

I think I'm almost able to get this to work using a more manual process. I found that its failing on creating the user's home directory, not on creating the account in dscl (although it indicates its cleaning up the dscl record when the process fails). What I did was the following (replacing "username" with a valid AD account on an AD joined Mac):

sudo cp -R /System/Library/User Template/English.lproj /Users/username

sudo chown -R username:staff /Users/username

sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n username -h /Users/username

It successfully creates the cached mobile account. It shows up with the full name in Users & Groups, as pulled from the AD record. I just need to test logging in and using the account to be sure there isn't anything wonky with it.
The above steps are far less than ideal, so I hope a real fix comes soon from Apple for this one. Never a dull day.

I have a post up now with my findings:

https://derflounder.wordpress.com/2015/04/09/creating-mobile-accounts-using-createmobileaccount-is-not-working-on-os-x-10-10-3/

Duplicate bug report filed. Also opened a case with my Apple TAM. Speculation seems to be that by patching the vulnerability mentioned here, 10.10.3 broke createmobileaccount as it was relying on the unpatched API.

All:

The output from the failed createmobileaccount script posted by @bmarks is very similiar to the output that I get when I try to run the exploit that is called out here in 10.10.3:

Hidden backdoor API to root privileges in Apple OS X

acunning-mn1:~ acunning$ python /Users/acunning/Desktop/exploit.py /usr/sbin/jamf /private/var/root/jamf

will write file /private/var/root/jamf

2015-04-09 10:56:05.889 Python[18781:2924942] ### syncProxyWithSemaphore error:Error Domain=NSCocoaErrorDomain Code=4097 "Couldn’t communicate with a helper application." (connection to service named com.apple.systemadministration.writeconfig) UserInfo=0x7fefcb019d80 {NSDebugDescription=connection to service named com.apple.systemadministration.writeconfig}

Done!

I do not see this error on 10.10.2; the script lets me write to /private/var/root as an unprivileged user.

This leads me to believe that createmobileaccount relies upon the systemadministration service, which has been "patched" in 10.10.3. In other words, Apple broke their own shit with this update.

Joy!

--Andy

why not use JAMFs AD Binding tool and set it to crate mobile accounts?

@jwojda its not an either/or thing. Most people do turn that on. With the command line tool you don't need to log in as the user to create their mobile account which we need to do in many cases and obviously you can't insert "this is where user physically logs on to computer" into your shell script :)

But one of the biggest things is convenience. Example, when we migrate a user who has had their AD account changed from an old naming standard to a new standard, we have to delete the old cached account so their passwords will keep syncing, etc, we rename their user folder to the new matching name, check permissions, then create their mobile account with the new AD account name and make sure they are admins again and that their mobile account is created and there.
Its a lot easier for me to just have them log off and do everyithing on the command line and never have to ask the user their password than to ask them to log in a few times for me, then log out, etc. I can do the bulk of the work while they are at a meeting or out to lunch.

Many of our clients receive Macs in their home, away from any office locations as they may be 'work from home' types of employees. In some cases, they are many miles from the nearest company office.

We have a custom build process that sets up a temporary auto login account after done with initial imaging and binding to AD. When the user receives the Mac and they power it on, it auto logs into an "imaging" account which is very locked down with Parental Controls. It launches a custom app that prompts them to connect to the company network over VPN if necessary (or just plug into the network if they are in an office location) They answer a few questions about their location and language, and type in their AD username. It checks their AD account and then prompts them for their password. Once they enter that, a custom script runs to create their cached mobile AD account on the Mac and cache their password (after verifying it against AD) Its at this point that we use the createmobileaccount binary to create their account.
As you can see, since the user isn't physically connected to the office, there isn't a logical way we can just have them log in at the login screen to create their account. They first have to be connected to VPN which can't be done from the login screen unfortunately.

Without the createmobileaccount process working, our entire user setup process won't work. IOW, this is a showstopper bug for us until Apple resolves it. We aren't going to be moving to 10.10.3 until it gets fixed and we confirm its working again. While we can redesign our process to use the more manual steps I outlined above, its a lot of work to get around a stupid bug, so we'll likely not go that route and instead wait for Apple to fix it.

also opened a bug report with apple 20498120

Hopefully the fix will be an update to the ARD client or a similar update rather than waiting for the .4 update, since that's a longer release cycle.

@Serge I'm hoping so as well. But knowing how Apple is operating these days, I fear this will be something that gets low priority inside Apple and not get fixed until 10.10.4. Especially since according to Rich's blog, the accounts get created properly at the login window. Apple will claim there is a valid workaround, but there really isn't.

FYI, as documented in the comments on @rtrouton's blog post, the workaround for this is to create the home directory for the user before running createmobileaccount. We are testing this approach, but it does not seem to work on the dev seed of 10.10.4. Can anyone confirm our finding (within the constraints of the NDA, of course)?

Yes if the home folder exists and is owned by the user then createmobileaccount worked fine.

OK, it seems that our method for creating the home directory (we were using createhomedir) was the problem. False alarm!

Here is an interesting explanation of why "createmobileaccount" breaks in OS X 10.10.3 (and why a particular workaround works)

https://gist.github.com/pudquick/bf33b7f7ec2184c0b72c

Also - if you have not yet, PLEASE submit a bug report to Apple. The more bugs the higher the response they will have on this, so I beg of you to submit this bug ASAP! https://bugreport.apple.com

Bug submitted!

Good to know. The most recent response to my ticket indicated 10.10.4 did fix this, but I hadn't had time to test yet.

Happy to report this now fixed in 10.10.4.

@mm2270 Would you be willing to share your custom app for at home user account setup? I have to migrate some at home users ASAP.

Hi @spraguga Unfortunately, I'm not able to do that for a couple of reasons.
1 - I'm not the author of the custom application. It was written by a colleague in AppleScript Objective C
2 - The app has heavily customized code for our environment, so even if I was allowed to publish it somehow, I'd need to rip out quite a bit that is specific to our environment to make it suitable for public consumption.

Sorry about that.
If you can post some more specifics on what you need to do, there may be some ways to create a simple app out of cocoaDialog embedded in an .app bundle with Platypus to do what you want. I've written several little "apps" like that which can be effective in their own way.