Home folder redirection in Casper. Best practices?

You've already been down the recommended path for doing it and like the rest of us had unacceptable results. I personally tested this with home sync and it would error constantly or miss files and was generally unreliable.

The only other way is custom rsync scripts from a locally maintained account (not a local account!) that run at login and logout. This way also lies pain. I don't know of anywhere that actually does this sadly.

I've tried multiple different ways of doing this and none end in glory just a lot of guts.
We ended up mounting the network drive on the desktop and "educating" our users on where to save their documents. While we did have teething issues with some users it was a lot less stressful than managing sync issues.

Redirecting did work in the 10.5/10.6 time... we created a local home folder and mounted the network homefolder using the AD plugin after that an Applescript that was started by a launchagent at login. The script contained ln -s lines for every folder that had to be redirected.

It worked until MS Office 2011 didn't want to follow the redirection, also Adobe's Creative Cloud started to give error's.

At this time when a student logs in using AD credentials, we create a local home folder, mount the networkhome folder both using the AD plugin and start a shell script again by using a launchagent at login.

In the shellscript we make hidden writeable folders for Final Cut Pro and Microsoft User Data in ~/Documents and we lock (chmod 500) the root of the local homefolder, the local Desktop folder and the local Documents folder, so student are forced to save to the network home folder.

Safari needs a writeable Downloads folder so we couldn't lock that folder.

There is a difference between "Network Home Folders" and "Mobile accounts"

Above, what you are calling 'mobile accounts' is in fact 'Network accounts' or 'Network home folders'.

With Network Home Folders - (Network Accounts) - as expected there home folders lay on the Network server.

With 'mobile accounts' - the amount 'in use' lies on the Local Machine (but can 'optionally' by synched back to a network account)

Network Accounts don't scale very well on OS X, likely due to the kind of usage.
Everyone says - "don't so this ! - it will be horrible.."

Tech people not use to OS X, will often think it's a good idea, since on the face of it seems so..
It's just that in practice it does not work very well at all - certainly not for hundreds of users
(it may work well for a few users, but hit's I/O issues for many users)

I would recommend either using un-synched 'mobile accounts' (yes not even synching them)
or AD-Bound local accounts. Either of those (which actually amount to much the same thing)
would work very well.

We tried mobile account synching, and gave up on it - it simply was not worth the bother.

This does not prevent you from setting up Network Home Disk mounting i.e. as an auxiliary archival drive, rather then as a home drive.

Keeping the home drive local, makes the CPU work much more efficiently, and is not slowed down waiting for network I/O.
Additionally as mentioned above - some applications won't play well with Network volumes.

So that's my take on this.
Use Network Volumes for archiving to, not for running off of..

@adriansimmonds generally speaking we avoid this type of setup. When we have had to get users data into network homes automatically we have gone down the scripted route. There's a few reasons explained in my Penn State talk last year: https://www.youtube.com/watch?v=X8e2gyS8n_Q

If you have to re-direct folders, I would definitely avoid the library folder.

As @Niels.Illem mentioned, the last time this sort of "worked" was in 10.5/6.

Hope you get something working for them :)

Thanks you all very much, those responses have been helpful and confirmed what I suspected, to be honest.

Based on this, I feel more inclined to advise the customer as to why their proposed method probably won't work for them in the long run and try to steer them towards something a bit more robust, but we'll see.