My name is Armin Briegel. I'm a Server Consulting Engineer for Apple Education. And today we're going to talk about network home directories. This is one of the sessions where we talk about stuff that's current today in Tiger. So stuff you might take it home right away. But we also have lots of nice new good stuff in Leopard, which you can look forward to in October.

So first, a few things that we're all on the same page. Why would I even want to do network home directories? And the most common reason, obviously, is to centralize the data, to get the data off the client machines, so that people can maybe move between machines, very common education scenarios where we have labs.

But in some businesses, they can switch between machines depending on the application. If you set it up right, you can even access the data from different operating systems. You can log into UNIX and have your home available. You can have the same data available on Mac OS X or even Windows.

And centralizing the data, getting it, everything into one spot also makes the back-up plan much simpler. Most back-up companies charge by volume and client amounts. And I hope nobody's in the room here, but you can save a lot of money by reducing the client licenses because you're only backing up a handful of servers instead of hundreds and hundreds of client machines. So that helps a lot as well.

Is there a range for this thing? There we go. Also, once I've moved the data onto the server it exists independent of the client hardware. And especially nowadays, everybody here has a laptop open, everybody everywhere has a laptop because we want to move the data everywhere, want to be in Starbucks, want to work in the airport when we're traveling.

That mobility has a risk because the data might get lost because the laptop might get lost, stolen, breaks easier because it moves all the time. We have all this fancy stuff like the MagSafe adapter and sudden motion sensors but still they move a lot. So if I have my data on the server that's a much safer place. I have raids. I have large redundancy. The room is locked.

Simplifies hardware upgrades. I don't have to worry about the user data because it's on the server. I can just reimage the machine if something goes wrong. It shouldn't be your first choice of action but at least it makes it much easier. And for some system admins it's the backdoor where you can get to introduce client management even though the users might not like it. Because you need client management for network home directories. And you can tell them all the benefits just don't mention the client management part.

There's five different approaches on how to handle the home directories. Well, there's four in Tiger and one is new in Leopard. The first one is local home directories, which is basically no network home directories, but that's an approach. Then there's guests or generic accounts. The real true network home directories and then we have portable home directories, sometimes they're called mobile accounts depending on where you look in the documentation. And external accounts, which are new in Leopard.

I will be mentioning a lot of services and servers. Three, three parts are essential for network home directories. I usually need some kind of directory services, essential directory where all my user data is stored. I probably will be referring to Open Directory a lot because that's what I use. That's what I sell. I'm with Apple. But it could basically be any directory server. Because the Open Directory framework, and I'm referring you to the Open Directory sessions there, will basically work with anything that talks LDAP.

You need a file server or a home server. Again, I will be referring to Xserve and Mac OS X a lot. But basically we work with anything that serves Samba, NFS or AFP and then the client machine, which definitely has to be a Mac for today because we're talking about home directories on a Mac. And the client machine has some kind of means to authenticate against the directory servers and then mounts the home directory.

So just briefly, this is what a lot of people are doing as their home directory strategy. We have local home directories. I log in locally. My data is locally on one machine because that's my machine. And that isn't a bad approach depending on what you want to do. I don't want to diss you too much on this. The system might actually still be linked to a directory service and I can still use central authentication and get the user information off the network but the user is stored locally.

And usually there's some way the user mounts the network share, moves tiles back and forth, then I have my central storage. And there's some user training involved. How do I mount that? Do I automate that? There's some nice ways in Workgroup Manager to automate the mounting of the user share and then whatever is on the server is safe. What's on your machine isn't.

And Active Directory actually made that kind of visible. There's this option which is called for false local home directory and start-up disk. So even though the user information comes out of the Active Directory, the home directory is local and the user might or might not get to link in the doc to his network share. And there's ways of doing that in Open Directory.

Generic Account is a similar approach, probably one step backward depending on how you look at it. Very common in labs. You have one student account and a password that's known to all. If you're really fancy the password gets cycled every month but usually it's just something generic. It used to be apple apple for Apple's demo machines but that's a few years ago so I thought it would be safe if I put it up here.

This has a lot of disadvantages. All users share the same data in the home directory. They might, I might be able to see what the guy in front of me did. Go into the Safari history might be interesting. But the main advantage is its simple. I just put two or three accounts on it when I make the machine, and I just blast out using net restore, net install. It's really simple to manage. I don't really have to worry about that. Obviously it's a huge security hole. Not only might anybody log in and do stuff I can't really track who did what. I might be able to track what machine did what but that's about it.

So there's some improvements to that and the main and obvious one is the self cleaning user account and it's obviously to avoid the unintended data sharing. You have to put something like these three lines. I just put the stub. I thought this was the developer's conference. You can write your own scripts.

But I put the main information here and you have to remove the home directory and restore it from some kind of template. You can use the standard template that's in the system library or prepare your own standard template with maybe some special things on the desktop or some notices. And leave that, put that into a log in hook. One hint is go to Mike Bombich's website. He has the entire explanation how to do this.

We've simplified this a lot in Leopard because we kind of made it official. In Leopard we now have the option of guest accounts. And a guest is a special user on the operating system that actually has no password. So then you have to remember the password. And basically the guest account will be wiped every time the user logs out. So that's a feature you can enable and work with manager. You don't have to worry about it anymore.

So the real network home directories. To enable network home directories we have to have an automount record. It stays the same from Tiger to Leopard. We still have to generate the automount record. It moved from Workgroup Manager into server admin, in case you're looking for it on the developer seed.

Most people forget to create the automount record, everything else set up, Open Directory, but they didn't create the automount entry for the user's directory and then network home directories won't work. If you're using a system other than Open Directory or an Xserve you have to create that manually.

Then you get the option in Workgroup Manager under the home tab where the home directory of the user actually lives and you can log in. We introduced something new and that was a big deal last year. I remember being at the session where they introduced they were moving away from automount to auto FS. And now I'm standing up here saying use automount. We have both in Leopard.

We have to keep automount for backwards compatibility. There was a question in the earlier session where, how's the support if I have Tiger clients with Leopard server or vice versa? We need to remain, keep automount around for that. We still generate the same automount records. So if you have entirely Leopard deployment with our Leopard clients you could move to auto FS if you have a non-Apple deployment with some other operating systems and are already using auto FS, that's definitely the way to go. If you have a mixed environment with Panther or Tiger clients then automount is still there and is still the default.

Automount is especially troublesome if you have a large number of automounts. Large number being more than 12, depends on the usage pattern. So be careful in what you, just don't go crazy and create lots of automount records. And for NFS our recommendation, the best practice seems to be to not use automount but to somehow mount the NFS share using a start-up script. That works much better.

The templates for the user, they live in the system library folder. They actually quite well down, they're in system library user templates, and this is the one exception to the rule that you should never modify anything in the system folder. You're supposed to modify the user templates in this folder. There's a lot of folders in this user templates folder and they follow the usual localization process. So most people will probably want to modify the English dot LPROJ folder in this user templates folder. It depends on the language of the admin who set up the machine.

So if you set it up in German or Japanese then you have to modify the Japanese or Deutsch dot LPROJ. Once you've created your template the template will be used to create the home folder either very lazily, as soon as the user logs in for the first time, and the server notices there's no home folder at the spot where it's expecting it to be.

You can force that in server admin using the create home now button. Or there's a command line tool if you want to mass create those. Look at the create home dir tool. It's very easy to create home dir dash A, will create all folders that aren't existing yet.

Or you can use it specifically for a user. We have three protocols as choice. Generally for file serving you can use NFS, AFP or SMB. You can also use each of those for home directories. We only support Samba for home directories in conjunction with the Active Directory plug-in.

NFS, one of the pros is Kerberos. At least with Leopard we get Kerberized as NFS, which makes it really nice and easy to use. You get authentication over NFS. And it's easily provided. NFS is probably the most common denominator, especially in education environments there's always some Linux machines standing somewhere serving NFS home shares.

The nice thing about NFS is it allows for fast user switching between several network home users. We can't do that with AFP or SMB because we can only keep one authenticated AFP connection to the user share at the same time. So I can have local users and one network home user with one AFP. With NFS I can switch between multiple users with fast user switching.

Disadvantages of NFS, extended attributes, must be emulated. You get the dot underscore files on the NFS, which might be ugly if you use it for different Unix systems. The case sends it to file system. Most applications are Ok with that but not everyone. So test your applications. And obviously NFS, there's some security considerations because it's before Leopard with coberus NFS, it's not an authenticated file system. If you have NFS running you're probably beyond that.

If these are native default, obviously we have the full HFS plus feature support, resource forks and extended attributes will just work. It's Kerberized in Tiger and Leopard, which is really nice. It's a good user experience and also very secure. It can be easily served from Mac servers, obviously. Windows servers usually have good AFP support.

Not all of the features are on most Windows servers, depending on which solution you use to add AFP to Windows It's probably the best performance you can get. And AFP supports auto reconnect so if the client goes to sleep, wakes back up there's certain protocols it does to try to reconnect, try to find the server, rebuild the connection. Again, the mobile laptops, they move around, change their networks, they will try to reconnect.

Disadvantages of Mac OS X is scalability of Mac OS X could be improved, will be improved in Leopard. If you're working on Tiger AFP is probably not something you might introduce into a non-Apple network, might want to use one of the other solutions there. SMB is Kerberized as well. It is also easily served for Mac, Windows and Linux servers. SMB is really common on Linux as well.

Also gives you a good perform, not quite as good as AFP but very close. With Leopard we will gain auto reconnect support for SMB so same features as in, or similar features as in Tiger. With Tiger we don't have that yet. And it is probably the most friendly solution if you're in a Window centric environment.

With Tiger you might run into problems, not everything is as nice. I think with ten, for nine and ten we probably have most of the issues out. And it is only supported if you use the AD plug-in. So if you want to use some other directory system in SMB it will work but don't come running to me or AppleCare for any support. The extended attributes have to be emulated on Windows but then again you could probably use ACL's and Windows if you wanted to use that resource forks, again, will generate dot nsco files.

The thing with the network home directory is great. I log in, everything I do in Mac OS X goes into my home directory because that's the one place where the operating system knows that I have privileges. I can write into that. So I write everything into there including the caches.

That's not something you want to send over the network back and forth. Safari uses caches so then can use the local fast disk and not use the network and then I'm sending it over the network again. The local network might be faster but it's not really something you want to do. So you can redirect those folders.

I'm doing this with the example of the caches folder. You could basically pick any folder you want. Theoretically it should be Ok if you did this once but just to be safe we usually put it in a log in hook. You delete the caches folder or back it up, rename it and then replace it with a symbolic link. We usually put the actual caches folder direct symbolic link into the temp folder.

Temp folder obviously has the advantage of being cleaned at restart. So you don't really have to worry about that. But you could put it elsewhere if you were worried about that if you wanted manual or wanted to keep it around. You could do this with other folders as well.

There's some challenges with network home directories especially over wireless. Imagine a mobile card, 25 laptops, one Airport base station and you have 25 students logging in at the same time over Airport B. That's obviously a challenge. Yeah, the log in takes about five to ten minutes. Yes.

And one of the Airport base stations freaks out, doesn't want to do anything.

Then we have to log in again, the machines might freeze because the network share just disappeared. Or even if it doesn't freeze we'll get the spinning wheel because it waits for the server to come back. We have a reconnection in Tiger for AFP. We'll get it for SMB and Leopard.

NFS will just freak out. You will get time-outs over a slow network. Again, the mobility thing. What if I want to take my laptop home, on the road, what would sales people or teachers want to work everywhere, at Starbucks? So that's why we introduced portable home directories. They were introduced in Tiger, which is two years ago and they've served us really, really well. Depending where you look they may be called mobile accounts.

There's a probably a slight different, mobile accounts are just synchronizing the user account information. Portable home directories is everything but not everybody really makes much of a difference. And you turn it on in Workgroup Manager. This is a snapshot from Leopard where you have a few more features.

So when the user logs in he gets a prompt or not. You can suppress that if you want to as the admin. Do you want to create a local home directory? And if you suppress that but want to create the dialogue for some reason, hold down the option key at log in. As usual that reverts all your settings.

Then the user's account information is copied from the directory service into the local directory service, net info on Tiger, the local database on Leopard and then it will copy more. In Tiger it will actually try to gather all the groups, all the groups into the local database, which might be fun. So take care of that.

In Leopard it'll be a little smarter and it'll only gather the groups that the user belongs to into the local directory service because those are probably those that I might need. And then the home directory synchronize between the client and the server. So basically on the first try it is copied downwards toward the client according to the sync rules that you set up.

So this is the dialogue of the sync rules. You can set folders and wild cards and individual files that are synchronized. You can exclude folders and files that aren't synchronized. And Mac OS X server comes with a list of stuff that you probably want to do and that you certainly shouldn't do and these are the defaults in Leopard. They're a little extended over what we have in Tiger. And you can set synchronization rules for log in and log out, they're the same.

And they're probably more specific. The one thing that comes to mind is the library folder. That's just up here. We can't synchronize the library folder in the background because there's dozens and hundreds of files in the library folder that will probably be open while the user is logged in. So we don't synchronize that in the background. So we want to synchronize it at log in.

And then there's a background sync which will happen at certain intervals in the background while the user is working. You can add inclusion and exclusion rules. So one of the best practices after two years of doing this that we've sorted out is if you have a wonderful big Xserve RAID or you're going to buy one, please, ( Laughs ) You can synchronize everything. That's great. The users will be happy and your Apple salesperson will be happy and you can keep just buying storage.

But if you want to somewhat control that the best approach probably is to synchronize the desktop because, honestly, everybody stores everything on the desktop, nobody goes to the documents folder. And even if you try to teach them to and the documents folder, because that is sometimes the default, sometimes things end up in there. If you're concerned about storage you probably don't want to synchronize the movies, pictures and music folder. We don't want everybody's iTunes library and photo library on the server.

But if you do that, tell them so. They will be very unhappy if they use their iPhotos and weren't aware that it wasn't synchronized. It's really easy to write a small Automator applet. Go visit the Automator session which says take the movies, picture and music folder and burn it onto DVD. Hand that out, they will be happy.

But just teach your, train your users to what you are doing. You can't put wild cards in the synchronization rules. And everybody says, Oh, that's great, because eventually the users will figure out that they can move the iTunes library and put it in the documents folder and then it ends up on the server again and, and so you as the admin say, This is great. I'll just exclude star dot mp3 and m4a and all the other flavors of audio that are out there and things like startup mauve.

It might work for awhile but think about applications such as Keynote or iMovie or OmniGraffle or all the others that don't have binary files as their documents but they're actually packages and in the package folder you can find all the resources. So if somebody adds a dot mauve file to the presentation it won't be synchronized to the server. The Keynote will be synchronized but not the one movie in there. And when we have to synchronize back and forth and move to another machine the Keynote file will be broken. So it's very...Be very careful with generic wild card inclusions and exclusions.

It's kind of paradoxical and you have to think about for awhile but especially in classroom environments where I have a really good rhythm, every hour lots of students log in or wake their machines from sleep and then they close it after 45 minutes and move somewhere else, shorter background cycles, background synchronization cycles will actually lessen the load on the server.

You will get this background noise of trickle synchronizations and because it was only four or five minutes since last synchronization nothing much will be moved back and forth. If I set that to an hour or two I will get huge peaks on the server because everybody turns it on at the same time.

If you're in a business environment where it's more spread out when people log in and log out you'll probably do fine with longer cycles but it really depends on how we deploy that. And, then again, train the users, tell them what you are doing so they know what gets synchronized and what doesn't.

There's a few extra sync defaults. Sometimes it happens if users move between machines. And you can actually have multiple mobile accounts on different machines and move back and forth in between them and if you take care to log out before you leave one machine you will actually get the most recent data on the next machine. That works quite well.

But if you logged in at the same time with two machines or you didn't really do the log out synchronization because you just slept the machine, you will get conflicts and dialogue pops up and it will show this two files conflict. Do you want to keep the one on the server or the local one? Some users will be challenged by this. They will be, What do I do now? So you can set default rules. How do I resolve a log in conflict? And you have two choices, the server always wins or the home always wins.

And how do I resolve the background or the periodic synchronization conflict? And then we have a third choice. We can show a conflict dialogue that's the default. You can set it back to that. So if you have users where you want to, In a real one to one environment where most users use one machine all the time setting it to the local machine always wins, is probably a good choice.

Or you can suppress the errors entirely. This isn't the conflicts. Sometimes things can't be synchronized usually because it's some weird dot FS temp. Anybody ever seen that? They appear sometimes. You should exclude those generally, exclude dot FS temp star helps a lot. Sometimes locked files or some privileges will keep the machine from synchronizing, then an error will pop up. If you want to suppress those don't stress the user, This is how you can suppress those.

If you're having issues with the entire synchronization process the usual things apply. Check DNS, check Open Directory, check the file server. If you think it's the synchronization process you can and able the synchronization debugging with the following command, zero is the default, which is very minimal logging. The mirror agent will log to this log what, when it starts and when it stopped and some errors, but one to four is increasing detail. Probably want to start it too. And probably want to combine that with directory service debugging because usually that's the cause of most evils.

But the one thing with PHDs especially in a very mobile environment where people move around from machine to machine is, I leave a home directory everywhere I log in. We call that the rabbit droppings problem.

Depending how large your home directories are that might be a problem or not. There's two solutions to this. One is devise some kind of strategy that one person gets more or less the same machine all the time, seating arrangement in education, sometimes that's not possible.

And well, you can just go in and manually delete the user's account. Go into the accounts pane, the user will pop up there as a mobile user, you can just delete it and it will be restored the next time the user logs in. That's very easy. You want to script that.

Remove the home directory and remove the user information, the directory using DS scale because nickel will go away in Leopard. Yes! So you could script that and either run it as a launched job or blast it out with ARD or make it part of your update cycle or whatever. Well applet has added something really nice to that and we have expiring portable home directories.

And I put up the dialogue for that. And basically you can set a certain amount of days and if the user hasn't logged in in the last five days, ten days, 120 days, whatever, the system will delete the portable home directory and the user account to free up space. This is really nice.

If you set this to zero it will delete the portable home account at log out, which seems kind of counterproductive but if you use applications like Final Cut Studio or iMovie, which are really disk intensive, you don't want to work over the network you want to work locally and then this kind of makes sense. It would be nice if you could keep it a little longer but it works.

External accounts are also new in Leopard and they're an extension to the portable home directory idea. And basically it is a portable home directory but the user folder is stored on an external hard drive, probably one that can be removed easily such as a USB or FireWire drive or a USB key.

And if I take that key and go to a different machine, which is connected to the same Open Directory server, the user will pop up as an account on the user list, the machine has cross referenced with the Open Directory server whether it's actually Ok that the user can log in there. And then I can log in and work on my USB key or my USB drive.

This is another solution for not filling up the local hard drives with all the user data because the user has it in his or her pocket. So this is really new in Leopard. We haven't really tested this but I'm kind of excited about this.

We've tested it in Leopard obviously but we haven't tested it in any large field employment. I'm kind of curious how people are going to use this. So, Oh, wait.

This brings me to the demo. So here we are in Workgroup Manager and when using Workgroup Manager, I don't know if you noticed, is that we added one tab up here. We can now manage preferences. We've always been able to do it on the user, the groups and a computer list level. We've now added one more level, which is individual computers.

I don't think that will be used a lot but it will be interesting. Right now I'm working on the computer level. Mobile home directories are something you want to manage on a computer list level or a computer level because it's pretty hardware bound. The classroom with the iMacs which are tethered to the network probably don't want to use portable home directories.

The mobile computers you probably want to do. You can turn on this setting on the user level as well. I can have a group of users or an individual user who can use portable home directories but then the dialogue will pop up every time he or she logs in anywhere, which might be annoying.

So first of all in the, in the log in panel I have the choice, And this has been available in Tiger up here. This will show me a nice green blob at the log in window, which will show me that my network server and my Open Directory server is actually available. It was a default command hidden in Tiger and it's now in the graphical interface in Leopard. They're kind of like that. Directory status is probably the most useful but you could display other kinds of information there, which you might find or the user might find interesting.

Then under the options tab in Leopard, down here I get the option of enabling external accounts and enabling the guest accounts. And this is for a computer list or for a certain piece of hardware. And then I can go into the mobility part and, I have to select my - So here it says the user will be prompted to create a mobile account and it will require confirmation, will show the dialogue.

I can even disable the functionality that the user says don't ask me again, because then, obviously, the dialogue won't ever pop up again. And I can, either I can preset the sync settings, I guess that's the most common, but I can also leave the choice to the user what gets synchronized and what doesn't.

Firewall, did it mention that in the slides? Firewall doesn't really work well with portable home directories in Tiger. We now support it and you can enable it in Workgroup Manager with Leopard. ( Applause ) And if you use Firewall you can restrict the size of the user home directory in conjunction with quotas on the server.

So that's a really nice solution. And down here I can set the home folder location. So by default it should be the startup volume. If I want to use external accounts I can give the user the choice and move it to an internal or external volume or I can preset the path on where it belongs too. So if I have partitioned all of my machines I can set the home directory to be on a certain partition.

And here is the account expiry and that's when the mobile accounts get deleted. Now if you set this once and you set it to always and it's been pushed out to several machines and then later on you say, well, portable home directories, I don't want it in that classroom anymore and set it to never, all the portable mobile users that already exist on that machine won't magically go away. They will stay on that machine and they will continue to work as portable home accounts. So you will, in addition to disabling in Workgroup Manager, you will have to remove the accounts in the local machines, otherwise they will just remain portable home directories.

And if you just switch it to never in here the preferences on the machines actually won't be affected because all that you changed is I switched it from enforcing that preference to the Open Directory doesn't really worry what happens there. So it remains the setting on the client. If you want to disable it on the machine you have to keep this on always and actually go in and disable it here. That way you are really disabling part of home directories. That leads to some confusion.

Can I go back to the slides?

One thing that really supports network home directories, portable home directories, any kind, is group folders and it's been built into Mac OS X for awhile. But I know that several admins aren't really aware of that. Group folders are home directories for groups and I can set them in the Workgroup Manager UI and I can also have an option of saying provide links to all of these groups in the doc. So all of the groups that a user belongs to, when he or she logs in, a link to them will be provided in the doc. They won't be mounted automatically.

I will just get the link and as soon as you click on the folder it will actually do the mounting. And this is really great for Workgroup Manager. In Leopard we have the new directory app so the users, if you allow them to, can actually create ad hoc workgroups by themselves and then they will get their own group folder and then can share the workflow.

Some things like drop boxes might be a little challenging in a group environment so use ACL's. There was a session today, if you missed it you can go see it on the videos when they come out. Use ACL's for really good permission control here otherwise you will get confused users. And in a large deployment you want a dedicated server for the group folders.

So one of the questions I get a lot is I have 700 users I want to provide network home directories, portable home directories, group folders. How much servers do I need? How do I scale that? And over the past years we have built some rules of thumb. But before I show them, these are very conservative estimates. These heavily depend on the actual user profile that you have.

Are you doing Final Cut Studio? Are you doing just Word and Excel? Nothing against Word and Excel but the files are much, much smaller than Final Cut Studio. That will obviously impact your server. How often does a user log in, once a week, every day? So these are conservative but they are very good and they have served as well as rules of thumb. So first of all I need an Open Directory unless there's a directory server present.

And there's a limit Open Directory can handle 1000 concurrent connections. And using network home directory's managed clients and portable home directories, the client will actually send a few requests, not only at log in, to the Open Directory server. So you want to have a little bit of area there. You want about 900 concurrent users per replica. If you have manually connected clients for group folder or if you're just manually mounting the network home you can connect a server or some alias or link. 450 concurrent users seems to be a good, good number.

If you do network home directories that's obvious the most load on the server, about 150 concurrent home directories. You can alleviate this a little for the server using the cache free direction and some other tricks but this seems to work well. And portable home directories are better on the user because it's just the synchronization. Nevertheless the server has to do a lot for the synchronization because it's comparing files back and forth. So you can probably double the number of network home users.

These are Tiger numbers. We all saw the slide in the IT state of the union. AFP performance has improved a lot in Leopard so I expect these numbers to change in Leopard. And this is for an Xserve. Xserve G5 or Intel Xserve, doesn't really seem to make much of a difference.

So for about 100 users I'd recommend two servers. One of them will be running Open Directory. The other one can be the Open Directory replica. You want to have that just for security reasons. Open Directory is a very important vital. One can handle the group shares and the other can handle the home directories. And you'll probably be fine with this setup.

If you have about 300 users I'd recommend splitting out Open Directory and the file servers. Use one server for the group shares and two servers, spread out the home directories among the two servers. If you need lots of storage you can attach a RAID either directly or through a fiber channel switch.

And don't forget backup. Portable home directory is great because I have a kind of automatic mirror between the client and the server and if the client gets lost for some reason because it was stolen, lost, the hard drive failed, the data is still on the server at least up to the last synchronization. But it doesn't replace a backup because obviously if the user accidentally deletes the important Keynote file it will be gone on the next synchronization on the server and it's really tough to manipulate the mirror agent that runs automatically to not delete accidental deletions on the server.

So don't forget the backup solution for this. You've centralized everything, it's really easy to backup all the home directories. Of course, in this slide I put up everything with Xserve and Xserve RAID. Please go out and buy this. But basically you can replace any piece of this with something else, though we don't like that. If you want to scale out even further Xsan comes to mind.

The advantage of Xsan is its clustered file system. I can combine a large number of Xserve RAIDs or just a small number of Xserve RAIDs into a clustered file system that is accessible by several file servers at the same time. They can see the same file system, it's file level locking.

And I can store all my home directories in one place and I can scale out with the servers depending on how many users I have. And if you use a content switch for the DNS load balancing, one that is session aware and probably pulls the file servers on how much they're doing and distributes that, it actually works really well. Don't try portable home directories though.

As I mentioned portable home directories will compare all the files and decide what to synchronize and with an Xsan setup I have one metadata controller, one server who handles all the metadata requests. And, I don't know, check your home directory, I have 220,000 files in my home directory. And if you have several hundred users hammering one metadata controller with 200,000 files each it won't be happy.

So don't try portable home directories on an Xsan or if you do don't come complaining about the performance. Go to the Xsan 2 session and ask them. Please give them feedback about this.

I'm curious about what they will say. And Xsan, again, it will scale storage very well, it's a very performant file system but it hasn't any redundancy in storage. So don't forget the backup.

Ok, I'm the Apple guy. I can tell you a lot about the theory. I'm out there a lot actually deploying it but you would probably trust someone else better. And with this I welcome Greg Nagel from the Disney Animation Studios up on stage who will talk about his real world experiences.

Thank you. My name is Greg Neagle, Senior Systems Engineer for Walt Disney Animation Studios and the lead of the Mac and PC deployment and engineering for the studios. So we're located in Burbank, California. We have about 800 artists and technicians. We use Linux, Mac OS X, Windows, Mac OS 9, Solaris and lots of other things. We're a very heterogeneous environment.

So we need to integrate with what's already there. So at the core we're a Unix shop. At the backend there's mostly Solaris and Linux. Our directory is an LDAP directory. It's currently running on Red Hat directory server. It's run on Open LDAP in the past. Network storage, we have a variety of different types of network storage but the one that our network homes are served on, is served up via net app. And that's via NFS to most of our clients and via CIFS to that poor client that doesn't really talk NFS very well. They make it in Redmond.

So we needed to make OS X client integrate with the existing environment. We weren't going to bring in a bunch of Apple equipment to replace perfectly good home directories and the LDAP infrastructure that was already there. Fortunately Apple makes it really easy. So for LDAP you open up directory access, you add your LDAP server and we were fortunate enough that we could choose one of the presets, which is the RFC 2307 schema and now our OS X clients can log in with the exact same user name and password that our Linux clients use.

Now I'm cheating a little bit because that's how we started and then we went back in and tweaked stuff to make things work really the way we want to. But it's a good starting point for anyone, try one of the existing presets and see if it works for you if you have an existing server. So that's half the equation. The other half is you've got to have access to network storage and, as I said, that was NFS for us. Apple doesn't make that quite as easy.

The automount from Tiger and previous revs of the OS is really strange. It doesn't act like the automounter in any other Unix or Linux operating system. So, again, we have an existing Unix, Linux infrastructure. We keep our auto FS mount maps up on LDAP but the OS X Automator doesn't know anything about them, doesn't know what to do.

So we had to write a custom script that queried LDAP, grabs those automount records, rewrites them out in the format that the OS X automounter likes, writes them to the local disk and then manually calls Tiger's automount for each of those automount maps. And now we finally have our NFS directories mounted the same place the Unix clients have it as well. And that works pretty well, works great for our desktop bound machines.

Our laptops, a little bit harder because laptops aren't always on the network. People, they, they take them home, they unplug them, they use them on wireless, they have the audacity to restart them while they're at home and they can't get to the NFS shares. So we had to come up with a solution for those people and then we had to write yet another custom script. This one watches for network transitions. So we've unplugged the network, we plugged in the network, we've connected via 802 dot 1X, we've connected via VPN.

Looks for those transitions, then it goes out and sees, Can I see the Disney Network? Can I see the NFS servers? Oh, good. I'll bring up the automounts or not as the case may be. That's a lot of custom scripting. Every time the OS changed or we changed the backend somewhat or they move from one LDAP server to another I had to go in and tweak those scripts and that's kind of a pain.

So there's hope in Leopard. As Armin mentioned they're moving to auto FS as the standard or the new automount daemon in Leopard and that's the same daemon that's used on Linux and Solaris and most importantly it's used on the Linux for us. At Disney Animation our LDAP servers already have those auto FS mounts. So our hope is we'll be able to point Tiger's, I mean Leopard's auto FS at our LDAP server and it'll bring down those maps and it'll just work, no custom scripting.

So next week I'll be testing that really having. ( Laughter ) Go. Alright, so I have to admit our situation is kind of weird. I mean most people probably out there are not running NFS homes. They maybe aren't using the LDAP directory. They may be using Apple's stuff, which is great or they may be using Microsoft's Active Directory and SMB homes. No matter what kind of network home you have you're going to face certain challenges.

I'm going to go over a few we faced. I think some of these will apply to you, many of them may apply to you, and what we figured out to do about them. So the key ones you'll see is you'll have, you may have challenges managing the configurations and the default preferences, quotas, caches, certain badly behaved apps and then we'll talk a little bit about home, or portable home directories.

So if you have a local account and you create, or if you create a local account on the machine the OS prepopulates the home directory. It puts in all the folder structure and puts in default preferences in library preferences. You get the default doc and you get the experience that you expect. And I'm sure many admins have customized the user default so that they get the user expect that they want the users to have.

If you're fortunate enough to have OS X server and Open Directory you can get the same effect by doing that on the server. And when the user logs in they get your customized environment. If you're using Active Directory or a third party LDAP server you don't get that.

You log in and it's just sometimes an empty home directory maybe it's just whatever was on there from when it was being used by a Linux user or a Windows user. And so now you've got to go down there and help them setup all their applications and that becomes a pain really fast.

So what we did is we wrote a custom application. We used AppleScript Studio to do this. It's almost entirely AppleScript. And what it does is there's a little script that launches at log in for every user and it looks to see if there's a file in their home directory. It's a file that starts with a dot so it's invisible to the users and the finder.

If it doesn't find that file it goes, Oh, this must be the first time this user has logged into this home directory. So I'm going to open up the Disney Animation setup assistant and walk them through configuring their account. And this behaves a lot like the OS X setup assistant in that it setups the default doc. It helps them setup their mail and all the other kind of, you know, hand holding the user through setting up their account for a first time use.

The next thing, quotas. Unless you have infinite storage on the network you're going to run into this. Most machines today have 80 gigabyte, 100 gigabyte, 250 gigabyte hard drives. If you have 1000 users multiply that by how much space you have to have on the server to give them the same amount of space.

You're probably not going to do that, especially since you have to back that stuff up. So commonly your users are given a quota and that's actually for two reasons. One, so they don't use tons of space but also so that one user doesn't hog all the space on the network storage and crowd everybody else out.

The problem is the finder doesn't know anything about quotas. It doesn't tell the user anything about what their space is. It definitely doesn't do it on NFS. I'm pretty sure it doesn't do it on AFP and SMB. So what happens is the users work away with their network home and they're saving documents and they're downloading trailers from the internet and leaving them on their desktop and they're putting stuff in the trash and never emptying the trash and slowly their network home is getting fuller and fuller and fuller and finally the server says, You know what? You're done.

It's full. We're not going to let you write anymore. So then they log out and all their applications that were running try to write out their preferences and they can't. So now we've got zero length files. And then they log back in and, Hey, what happened to my doc, my applications? They forgot how to connect to the mail server. My bookmarks are all gone. And they call us and complain.

So we look, Oh, yeah, you filled up your home directory. They didn't know. They got no feedback at all. So what did we have to do about that? That's right, you add another custom application. So we wrote a little thing that sits down in the lower right corner, they can, or actually the lower left corner. They can move it around anywhere they want but that's where it is by default.

And it's green when they have a reasonable amount of space left and then it turns yellow if their home directory gets a little fuller and it turns red when it gets up about 90 percent And if they click it, that little twisty triangle, they get a little bit more information telling them how close they are to being full, why that's a bad thing, what they should do about it and who they should call for help. And you'll see that, that number up there, I don't know if you can, it's kind of fuzzy, a thousand megabytes. That's a standard quota we have at Disney Animation. So it doesn't take much to fill that up.

So now they've got some feedback and they can actually do something about managing their disk space. Now I wrote this app and frankly it's a nasty hack. So I wouldn't really want to give it to anybody but if you want it, if you want something like this you can either bug me to fix mine and make it prettier, you could write your own or you could take a look at Quota Monitor Menu by Adam Gerson.

There's a URL up there. I'm sure you could also Google for it. It does a similar thing to the thing I wrote it just happens to be up in the menu bar and it shows how much disk space is left and, again, the user can click it and get a little bit more information, empty their trash. And he's done a fair amount of work to let you customize it for your site.

Next challenge, caches. I'll gloss over this really quickly because Armin talked about it. We did the same thing, we redirected caches to the local hard disk, rewrote our own script. You could write your own or if you're lazy, like I would be if this had come out before I wrote my own, see the network home director. This'll set that log in hook script for you and redirect the caches. It can optionally also redirect certain other directories.

Badly behaved apps. Now the nice thing is is that as time has gone by a lot of the vendors have gotten really good, the vendors have gotten much better. They've, they've forgotten a lot of their assumptions that they had in the OS 9 days and they're actually writing their apps to be better behaved on a multi-user OS that actually has POSIX permissions and the network might, the home directory might not live under slash users, it might be out on the network. But not all apps behave really well. There's one that rhymes with Ruhdobee Shmotopop.

If you work for a company whose first name rhymes for Ruhdobee, I'm sorry, but so for us the solution was, for these heavy users of this program, is we just move them to portable home directories even if they were on a desktop. These are users that have, you know, maybe a G5 or a MacPro.

And we're using portable home directories for them so that from Shmotopop's point of view,

It's working on a local file system. It doesn't know anything about the network file system. So it, it runs smoother, faster and the users are much happier because photo , Shmotopop,

Is, is just much snappier.

So portable home directories, I just mentioned them. Apple obviously designed them with OS X server in mind. All the management tools are based in Workgroup Manager. They really work best with AFP home directories but they're not limited to that. You can actually use them with Open Directory, Active Directory, LDAP, SMB, NFS, AFP.

That wasn't quite as straight forward as I would have liked to set them up in my environment. I probably spent about a week figuring out how to do it. And I wrote these really long articles up on this website that if any of you actually read all the way through them I'll be really impressed because they get really boring.

( Applause ) Oh, oh Ok. Good, good. One nice thing though is that going through that process I learned a lot about how portable home directories work behind the covers. So if you're interested in learning a little bit more about that if you check these articles out you might, you might learn something.

So after using portable home directories for a while in our environment, And we really needed to, We moved to these pretty heavily about a year ago because shortly after Apple introduced the Intel MacBooks and the MacBook Pros we bought a bunch of them. And people wanted to be able to use all the stuff they were using on their desktop including access to their network homes and that sort of thing but still be able to use them, you know, portably.

So we really had to get portable home directories working in our environment. So we, we've discovered some things and made some changes to the synchronization rules that I think you might want to consider. And if you look at the new defaults in Leopard I think Apple thinks some of these things are a good idea too.

So Armin actually mentioned this one. The big top level folders you might think about excluding them, especially if your business doesn't have anything to do with music, movies or pictures, you know, iTunes, maybe you don't want to back that up. Make sure the users understand that's what you're doing so they don't lose data.

Mail dot app. If you use Mail dot app and Xchange, Is there anybody here that does that? Nobody does that? Oh, one person. Me too. ( Laughter ) You might want to add an exclusion here so that the synchronization process doesn't back up your locally cached Xchange mail. Now this is a little confusing so for comparison this is actually part of the Tiger defaults in that it doesn't backup, it doesn't synchronize your iMac and your dot Mac mail because the assumption is that's up on the server.

If you lose it, you know, you just download it again from the server. Well, Xchange is exactly the same way. So if you use Xchange you might as well add that and then you don't have to worry about portable home directories synchronizing your cache change mail back and forth.

Now if you don't use Mail dot app you might be using Microsoft Entourage. Entourage has some real big challenges when it comes to, to portable home directories because it stores everything in one giant database file. And that's usually stored under documents Microsoft user data Office 2004 identities main, you know, several folders deep but it's in there. And it's one giant file, it's usually open all the time because the Microsoft database daemon opens it at log in and it's changing all the time.

So you don't really want to synchronize it when it's open because it's, You're probably going to get a corrupted file because it's being changed while it's being synchronized. So it probably should be synchronized the same way all the stuff in library, the folder is and that's at log in and log out.

So I would recommend that you make some changes to your default sync rules so that at log in and log out you synchronize documents, Microsoft user data. And then as a further refinement you might want to skip synchronizing the Microsoft Entourage temp folder. And then on the other side for background sync, which is also when people do manual sync, don't synchronize documents, Microsoft user data. So now what happens is that database only synchronizes when you log in and log out and it's left alone during the user's session.

So that solves the problem but it introduces another one. It makes the log ins and log outs take longer and how much longer depends on how big those Microsoft database is. There's really not much you can do about that because the alternative is corrupted databases. I suppose one other approach would just be never synchronize it and tell the user they're on their own.

But that might be feedback you want to give you Microsoft. There was a session this morning, How many went to the Time Machine session this morning? And again, the Microsoft user database is one of those things that Time Machine would have to backup every single time it ran because it's going to change all the time and it's a big, big file. Quickly, it would quickly consume all of your backup hard disk space.

One final thing and I'll turn it back over to Armin. If you use Norton Antivirus or Symantec Antivirus, when it scans your home directory it creates these big files in your home directory where it keeps track of what it scanned all that sort of thing so it can scan faster the next time around, you should probably exclude those as well. There's no reason they need to be copied up to the network. They're usually fairly big and it would just slow down the synchronization.

So that's what we've learned. I'll turn it back over to Armin to close up and then I think we'll have some QA.

So just a, Greg, you can stay here. We'll start anyway. Just a quick summary. Home directories, there are five types. You can't do them. Local home directories, generic accounts, which will be made much easier in Leopard. The generic network home directories, portable home directories, which are extremely useful, external accounts and Leopard. I'm curious what you're going to do with them.

And plan and test before you deploy, do lots of planning especially in the synchronization rules. Greg mentioned some of that. And there's some assembly required. You probably want to play around with these until they really fit yours. But the great thing is you can. We encourage you to do that.