Good morning, everybody. My name is Scott Barbber. I'm the Integration Services Manager for Apple Professional Services and Education, and I'm here to present to you Deploying Portable and Network Home Directories. So we're going to review a number of different home directory deployment models, ranging from the simplest of home directory models that is a strictly local home directory all the way up through mobile accounts and portable home directories, and finally finishing off with the concept of hosting network and portable home directories. And we'll be reviewing a number of features that were added in Leopard and talk a little bit about the impact of those new features to your respective environments.

So starting with the sort of simplest paradigm of home directory deployment, the local home directory, and this is essentially where you've got your home stored on your computer. This is dictated by a specific attribute on the user record known as the NFS home directory attributes and that attribute just refers to a local path.

In this case, /user/admin, for example. And this can be used with any account type. So it's a common misnomer that in order to have a local home directory, you must have a local account. In reality, you can configure any type of account, a local account, a guest account, or a network type account to have a locally defined home directory.

And we've added in past releases of Mac OS X the FileVault feature, whereby your home lives locally on your Mac but lives in an encrypted disk image. This requires your administrative users to enable this feature, and then you can set a master password so that, for example, if a user forgets his or her password, you still have a means to recover that data.

Now, new in Leopard, we've added a feature called the Guest Account. And the idea behind the Guest Account is to give you sort of a kiosk-style login whereby you have a local account named Guest, and at logout time, the contents of the home directory for that user are actually completely deleted. So there's just essentially no footprint for that user's previous login. This is enabled in the Account System Preference pane. So there's a checkbox for allowing Guest to log into the computer.

There's also been a new feature added to allow this to be managed. So if you're in an environment where you're managing policies for your Mac clients via Open Directory or via another directory system, you can actually enable guest access in bulk at the computer or computer group level. And if you'd like to find out more about managing Macs using Managed Client, I would encourage you to check out Session 517, which is Managing Clients and Preferences with Mac OS X and Leopard Server.

So in terms of how the local home gets created, if you have a local user and you go to the account system preference pane, that local home directory is created immediately upon you provisioning the account in the accounts pref pane. Now for all other methods that you might use to create a local account or to create an account, that causes the home directory to be created at the user's first login.

So again, for the guest user, for example, the home is created at login time, deleted at logout time. And then for your network users, again, that local home directory would be created at their first login. So the only time when you don't create the local home directory at first login is when you provision an account via the account system preference pane.

At the command line, there's actually a tool that's built into every shipping Mac OS X system called Create Home Dir. And this can be used to create home directories, and you can create them either for local users, network users, really any type of user. You can call this command, and what it does is checks the NFS home directory attribute, looks at that path, and then creates the home directory for you, depending on where that home is located.

The creation of the home directory is based on something known as the user template. And you can customize the user template to change the user experience. This is located in /system/library/usertemplates. Notably, because it's in the system folder, just be aware that this is something that can be modified or changed by a software update.

So the contents of this have to be owned by the root user, have to have the wheel group. Now, new in Leopard, for those of you who've had some experience editing this in the past, we've made some changes to the defaults of the template. One big change is that there's now what's known as an everyone-denied-delete access control entry on the major subfolders inside of your home directory. So for example, movies, music, pictures, et cetera, those things now all have an everyone-denied-delete.

This is more or less intended to prevent a local user from accidentally deleting one of those folders. However, your power users may express some frustration around the notion of not being able to easily delete one of those folders. So just something to be aware of. In addition, the local user gets a Dropbox by default as part of the user template.

And one thing that's been added in Leopard is an access control entry that causes anything dropped into there to get an inherited access control entry for the owner of the home directory. This corrects some longstanding issues around move operations and drag and drops into Dropboxes, resulting in the file still being owned by the person that dropped it instead of being accessible by the receiver, so to speak.

So just some general guidelines for editing the user template. First of all, edit this at your own peril, in the sense that it's located in the system folder, and it could be overwritten by a software update or some other system change. Check for hard-coded paths in the things that you put into the user template.

So example, if you want to copy a preference file into there, be aware that that preference file may contain a hard-coded path to the home directory of the user that created the pref file, and you may not want to propagate that out to every single user that's accessing your system.

In addition, make sure you clean up after yourself. So if you're going to do a bulk copy of items into the user template, be really careful that you don't leave things like passwords or pref files that contain sensitive user data, because that will get duplicated for every user of that system.

Now for Active Directory environments, local homes get special-cased ever so slightly. So there's a checkbox inside of the Active Directory plug-in known as the fourth local home option. And what this does is it programmatically causes the AD plug-in to return a local home directory for all users of the system via the NFS home directory attribute. And then it programmatically generates a second attribute.

It's known as original home directory. And original home directory is just an encoded URL back to your network home location. And so at the command line, you can actually configure this as well using the config AD And it's important to note that this actually generates a little bit of a small snippet of managed client policy on the fly that does two things for you.

First of all, it mounts the SharePoint where your network home directory lives at login time using your name and password. And then it also puts a link to your network home on the dock directly so that you can go into the dock and gain immediate accessibility to your network home. The note is this cannot be combined with portable home directories.

So if you want to use portable home directories in an Active Directory environment, make sure that you don't check the force local home box. Make sure that you either use the option to create a mobile account or set the mobility policy upstream in your management. All right. It's also important to note that this requires that in Active Directory users and computers that you've populated a home directory location, specifically that you've given a UNC path that refers to a specific network location. And that's populated on the Profiles tab in AD Users and Computers.

So now moving away from local home directories and onto network home directories. A true network home directory is a network account combined with a network-based home directory. So there's no local user footprint at all. And this retains sort of the Unix tilde concept in the sense that if I type in the command line tilde username, that that is a substitution for the actual path to my home directory. However, a true full-blown network home directory is exceedingly bandwidth intensive.

The general requirement for these are switched 100 megabit connections to the client and a recommendation of having a gigabit speed connection up to your server. This is not something that, for example, can be trivially deployed in a wireless environment, as there doesn't exist sufficient bandwidth to support all the small file and large file traffic associated with this. Also be aware that you're essentially tying your entire user experience to the network. And so as goes the network connection, so goes the user experience. This can also mean that bad application behavior can cause some significant end-user pain. For example, an application that might pull.

A given folder over and over again looking for changes to maybe update a script menu item or something along those lines. So why would you do network homes in the first place then, given some of those caveats? Well, it does give you an opportunity to centralize your data. So it becomes machine independent. Repurposing a lab, for example, becomes really trivial if there's no user data stored locally that I have to worry about retaining. This also can make it a little easier for you to deal with backup because the data exists independent of the workstations.

It means that you don't have to worry about backing up content off the workstations. You simply back the server up and your data has been preserved. In terms of how the network home gets defined, we talked earlier about a local home being defined strictly with the NFS home directory attribute. So in a network home directory environment, you have the NFS home directory attribute that refers to a network path.

Specifically, it starts with /network/servers, and then you have a host name and then some additional path item. In addition, you have an additional attribute called the network path. This is a shared relative URL that's encoded and stored in the home directory attribute. And I've included an example here.

To go along with the user record, you also have to have a mount record. And this mount record is accessible on the search path, and it can either be manually created in your local directory or it can be created using Server Admin and populated into a network-based directory system.

Once again, with Active Directory environments, this is a special case just a little bit. Mount records actually aren't required in an Active Directory environment because the AD plugin generates Mount records on the fly anytime it sees a user home directory populated on a user record. So again, the key is that you have to make sure that you've populated the Active Directory Users and Computers Profiles tab with a network home location.

In terms of accessing the network home, we do have support for three different protocols for accessing user home directories over the network. Starting with AFP3, this gives you full HFS+ feature support. It supports Kerberos authentication. We've had auto-reconnect support for quite a while. There are implementations available for Mac servers, for Windows servers, for network servers as well. There's also an open store stack out there, the NetATOX stack, which is available for other platforms as well.

Historically, scalability with AFP has been a challenge with network home directories, although this has much improved in Leopard Server. And there's no fast user switching support when you're using AFP as your network home directory protocol. That's because at any given time, only one user can be connected to that share.

So when you flip over to another user with a network home directory in that same share, there's no way to drop the connection and re-establish it as your newly connected user. So be aware that fast user switching and AFP network homes don't really go together. Scott Barbber Now with NFS, in Leopard Server, we added Kerberized NFS support. Implementations are available on all major platforms with NFS, and you get full tilde username support, meaning that any user can arbitrarily get to another user's home directory fairly trivially, for example, if there's public content that that user's hosting there.

This also allows for fast user switching, as you don't need to do any kind of an authentication switch on the connection. Bear in mind, however, if you use ACLs in your environment, that NFS limits you currently to being really connected to your network home directory. So if you've deployed ACLs, having NFS connections to your home directories will limit you in that sense.

Finally, we do have support for SMB homes as well. In Leopard, client-side support was added for auto-reconnect for SMB in Kerberos environments. There's also better NTFS stream support so that if you shouldn't be going forward creating those .underbar files that so many of you have expressed are challenging for you.

There's also Kerberos support for the SMB client, and this generally is the most friendly to existing Windows IT shops. However, Tiger and earlier OSs have somewhat limited support in this area, and this is only fully supported with the AD plug-in. So you'll notice that if you go into Server Admin, for example, that you don't see the option to create an automount record for anything other than AFP and NFS. That's because support for SMB home directories right now is exclusively limited to the AD plug-in.

New in Leopard is a feature called, that we call folder redirection. This is a client-side feature, and it's designed to really enable administrators to reduce small file traffic back to the server. So certain folders, for example, like the movies folder or the caches folder inside of the home directory can be redirected to a local location on the workstation.

This is activated by the managed client policies, and there's actually a specific key called the com.apple.mcx-redirector key that you would use. This, for example, then allows you to redirect the library caches folder down to a temporary location. And at this time, I would actually like to demonstrate folder redirection for you.

Okay, so I've opened up Workgroup Manager here, and I've got a user already defined in the system called Redirection. And what I'm going to do is go ahead and set up a Manage Client Policy for this user that will cause his home directory to be partially redirected. So I'm going to go into Preferences in Workgroup Manager, and I'm going to go to Details. There's not a specific icon that we use for this particular item. And I'm going to click this plus button, and I'm going to... Go into the System folder, into the Library folder, and then to Core Services. And I'm going to pick out an application called manageclient.app.

Once I choose "Add," you'll see that this added a number of different preference IDs and names, and the one that we're particularly interested in is the one marked here as "Folder Redirection." So I'm going to double-click that item, and I'm going to click the disclosure triangle here next to "Always" and choose "New Key." I'll choose Login Redirections.

Once again, click the disclosure triangle. Choose New Key again, and we see Redirect Action Info is populated. And I'm going to go ahead and just use the defaults for this demo because it makes life a little easier for us. We'll see that there's an action, which is the Delete and Create Sim Link action. There's a destination folder path. And it's a little tough to see, but there's a %@ sign. And that %@ sign substitutes in the currently logging in user's name into the path.

And then finally, the actual folder path that is to be redirected. So this action will redirect the contents of the Library Caches folder in the user home directory into the temp folder on the local hard drive of the system where I log in. So I'll click Apply now. And then it's time to actually put this into action and make it work. So I'm going to switch my system here.

Okay, so now at my login screen, and I'm going to go ahead and log in with my Redirection user. Oops. Pardon me. There we go. So you can see here that Redirection has a home directory that's located on xserve.pretendcode.com, which is my server, and it's located in the home directory share.

I'm going to specifically look inside of the library folder for this user, and we'll see that caches has been replaced with what appears to be an alias. If I double-click this, I see that this has now been redirected into the temp folder, into a subfolder with my current user's name called Redirection, and library caches. And that is folder Redirection.

Moving on from network--full-blown network home directories-- onto mobile accounts. So with mobile accounts, you have a cached network account combined with a local home directory. So user attributes are copied and then stored locally in the local directory system with a local home directory. In addition, your password hash is also stored locally. However, your network server is preferred if it's reachable. So this allows for offline access to the account if you are to roam off of your network.

New in Leopard is an additional feature that's sort of an extension of the mobile accounts paradigm called external accounts. And an external account is nothing more than a locally-cast account where the user's folder is also stored on an external drive. This is going to be a USB or a FireWire drive.

Key important piece to this is that the volume must be HFS+ formatted. So most of the time, your pen drives and whatnot come FAT32 or FAT16 formatted out of the box. Important to note that if you want to use those drives with this feature, they need to be HFS+ formatted.

So when you attach the drive, this actually makes any user who's had the account cached onto that drive available to authenticate. So the user actually shows up in the user list, and if the computer's not in the same directory domain, it will actually prompt for admin authorization to gain access to the local system. And rather than explaining this, the best way for me to show this off is to actually demo it for you.

So switching back once again to my system here, I've got redirection. I've got a new account here called external, so I'm gonna go ahead and use that one for this part of the demo. So, selecting the external account, I'm going to go to Preferences, and I'm going to go to the Overview section. So, there's a full UI for this particular feature. If we go to Mobility, I'm going to go ahead and turn on the mobility option to create a mobile account when the user logs in. And just for the sake of the demo, I'll turn off the requiring confirmation.

And we'll also turn syncing off for the purposes of this demo as well. We're going to go to Options here, and we'll manage this Always. And we'll notice that we have Home Folder Location listed, and it says On Startup Volume or At Path. I'm going to actually select the User Chooses, and I'm going to say User Chooses Any External Volume.

And then click Apply Now. So what this will do for me is that when the user external logs in, they'll be prompted to select a volume, and then I can actually have my mobile account provisioned not only in the local directory system, but also in that external volume. So what I did was I brought with me a pen drive, and I'm gonna go ahead and connect that to my other demo system here.

So I'm now prompted--create a mobile account. I get an explanation, and it says, "Select the home folder's volume." So in this case, I'm going to choose my disk, which is my external volume, and click "Create Now." And after a few moments, what's happening behind the scenes right now is that my account is being cached and my home directory is being provisioned on the external drive. So once I complete login, we should see that this user's home directory is actually located on the MyDisk external drive.

And at this point, if I log out, I now have the ability to take this drive and use it somewhere else. So I can move from system to system to system and immediately gain access back to my full account. And more importantly, I retain my full user experience. So I retain the characteristics of my login session. I retain all of the private system settings that I've historically been using. It all follows the user all on this small external device.

this takes us to portable home directories, just sort of the next logical step in the home directory evolution. With portable home directories, it's a synchronization environment. Your home directory on your computer is synchronized with your home directory that's stored on a server somewhere. It's important to note that this is not backup.

If you remove something from the server, at next synchronization, it disappears from the client as well, and vice versa if you remove it from the client, at next synchronization, it's removed from the server as well. So you don't want to run into the unfortunate scenario where a user thinks, "Oh, I can throw away all these things locally "because they're already on the server because I just synced," except that if the following sync, all those items would disappear. So the way a portable home directory works is that at first interactive login, you create a mobile account.

You copy the home using certain synchronization rules. The local template's actually not used by default. So we talked earlier about local home directories using the local home directory template. This is actually not used by default. Login and logout items are synced. So we'll talk a little bit about the notion of login and logout item rules. By default, the login and logout sync items are the library folder inside the user's home directory. Essentially, all of the items that you need to get in place and fully set up before the user's interactive session can begin. Then there are what are known as background items.

Those are things that would sync on an ongoing basis in the background as opposed to syncing at login and syncing at logout. Those items, however, are all synced at the first login. So if I'm syncing, let's say, library at login and then movies and music in the background, all three of those folders will sync at the first login for a given user.

Note that login and logout sync is a blocking sync. That is, the user can't get to the finder until all of the synchronized items are done syncing. Background sync is a blocking sync only on the first login. That is, the first login time, those things are synced. At all subsequent logins, they are synced according to a defined interval by management policy. That is, that either you say, "I'm only going to sync this manually," or "I'll sync it at a certain interval." Let's say 5 minutes or 20 minutes or an hour.

So just some general guidelines for synchronization rules. First of all, set up your rules by folder. For example, synchronize the Tilda document in desktop, but maybe don't synchronize movies, music and pictures. However, be really careful about excluding by file extensions. There is the capability to filter what you're syncing by file extension. However, we found that this can have some unintended consequences for end users.

For example, if you have a keynote presentation with a bunch of embedded QuickTime movies, those QuickTime movies are stored in the keynote presentation as discrete .mov files. And if you restrict syncing of .movs, you may have a user that create a PowerPoint--or sorry, that create a keynote presentation, and then that is synced upstream sans movies.

So then the next time they go to a new workstation, they sync all their stuff, they go to launch their presentation, and all the movies are missing. Why? Because they were contained in the presentation. Scott Barbber So if you have a keynote presentation, you may have a user that created a PowerPoint presentation, and all the movies are missing. Why? Because they were contained within that keynote bundle file, and your sync rule excluded them from being synced. So just a heads up on that one, something to be aware of in your environments. A shorter background synchronization time can actually lessen your server load.

So in periodic lab classroom type deployments where you have a lot of students coming in, accessing the systems, and then all logging out at the same time, if you sync all of those things, either at a very long interval or all at login and logout, you're going to have users waiting around for sync to complete. And as we're all aware of, that's not going to happen. And as we're all aware with our end users, a lot of times, especially if they're using portables, that lid will get closed before that last synchronization ever happens.

So having the background sync fire off pretty regularly allows data to be kind of trickled back up to the server pretty evenly. And it means that at logout time, you won't be waiting around for a lot of things to synchronize all the way at the end. Also, train your users to understand the concept of backing up their data still. I know this sort of seems intuitive.

But again, a substitute for backup. So just make sure that your users are educated into understanding that this does not provide a complete safety net and that backing up data is still important. Finally, look for things that you don't want to sync. For example, there's really no need to sync log files, cache files. There's a lot of data that you can pretty easily selectively exclude from your sync lists.

These are all things that the less items you sync, of course, the faster logins are, the better they use. So if you're using a lot of data, you're going to want to make sure that you're not using a lot of data. The faster logins are, the better the user experience. So just be really careful about how you're building your sync rule lists.

Now, new in Leopard is a feature that folks have asked us for in lab settings. It's expiring mobile accounts. And previous to Leopard, whenever you provisioned a mobile account, that mobile account existed on that workstation ad infinitum until somebody came and manually removed it. There was no way to automatically make these things go away. So every user who logs in, they would get a home directory and a locally cached account. But you can now set an expiration date on these things.

And what this allows you to do is to actually kind of turn off the mobile account locally. It actually just completely removes all of the user's footprint after a certain amount of time. So, for example, I might say, you know what? Go ahead and keep around this mobile account with a portable home directory for five days after the user's last login. So that if they log in again, they don't have to go through the complete re-syncing. They can only sync changed items.

But if they haven't logged in for five consecutive days, I'm going to assume that I don't want to retain that user's data on this workstation anymore. And I can go ahead and just remove that account at the next successful user login. The best way to show this off once again is to demo this.

So, expiring mobile accounts. So I've defined yet another account here called "Expiring." So I'll go into my Preferences folder here, Preferences area, and I'm going to go to Mobility once again, and we're going to go to Account Creation, once again creating our mobile account. We'll say with default sync settings. And we're going to go to our account expiry, and we're going to say always.

And check the delete mobile accounts option. Now, we see that this is defined in weeks, days, and hours in the GUI. For demo purposes, an hour really wouldn't work for us. So what we're going to choose is zero hours. And what zero hours will do is simply, at a successful logout, immediately delete the account.

So I will log in. I will work with a portable home directory that has synchronization enabled. And at logout time, my mobile account and my PhD will be deleted off the local workstation, thus leaving no footprint of my having logged in there. This can be very useful, again, for kiosk and lab type settings. So let's change this to zero.

You'll notice that there's a checkbox here for "Delete only after successful sync." So it is possible, for example, that you may end up in an environment where you don't want the local account deleted, even if the user hasn't logged in for 10 days, unless the system knows that one final last successful sync has been completed. We'll go ahead and leave that checked. So I'm going to switch over to my demo system here. And we'll log in as our expiring user.

My stuff. And I'm going to go ahead and synchronize my home directory.

Mainly to show you that if I look in my users folder here, you'll see that there is no remnant of that previous user account. So the account has been expired, the local home directory has been deleted, and then if I were to log in with that account again, it would be recreated for me and the contents would be resynchronized. And that's external--aspiring mobile accounts.

Finally, for hosting network and portable home directories, in terms of scaling for home directories, our general guideline is that your maximum number of concurrent connections for what we call a mounted home directory, that is a user passively accessing their home directory via connect to server, can go anywhere from 500 plus connections.

It's really, at that point, it has as much to do with your network and your use profile by your users. But at very minimum, you should be able to handle 500 in that kind of an environment. Now, once you get to portable home directories, there's a fair amount of file system enumeration that has to happen during the sync process.

So at that point, you're looking in the 300 range for concurrent connections for portable home directory syncing. So if I'm looking at a deployment of about 3,000 MacBook Pros, and I'm gonna have all of them using portable home directories, I might be looking at, well, what kind of concurrency do I have, and at any given moment, how many will be syncing? And I don't wanna have, if I said that maybe 600 of them would be in active use at any given moment, I would need at least two XSERVs to handle the load associated with those clients managing their portable home directories.

Finally, with full network home directories, where the entire home directory is stored server side, the general sweet spot for this is about 150 before you start to see some breakdowns in performance. Again, intensive, intensive small file traffic, a lot of file system enumeration, especially at login and logout time. So keep in mind that network home directories are by far the most intensive server side, load generating environment that you can have.

So in terms of how to improve concurrency, for true network home directories, leverage redirection. Get a lot of those things like Safari cache files out of the network home and get them into a local scratch space where they don't need to be preserved. This decreases the enumeration, decreases the small file traffic.

Monitor your application behavior as well. Make sure that you don't have apps that are doing really colossally silly things, like polling the contents of the home directory. For portable home directories, reduce the items that you're syncing and also leverage a new feature in Leopard called server side tracking for PHD sync. This is actually a separate daemon process that runs out of band from the file services connection.

It uses the FS events notification system to track changes to your network home directory. This reduces the enumeration load on the server because instead of the client having to comb the entire network home and look for what changed, instead, the server actually provides the client with a list of anything that has changed server-side, during that client's login session, and then the client can change those items without having to poll or to do a full run through all the contents of the network home. Keep in mind that this is not XAN compatible, so if you're using PHDs and you're hosting them on XAN, bear in mind that you cannot use the server-side file tracking feature.

Finally, XAN and home directories. So just be aware that XAN does allow multiple servers to share one file system, but beware of portable home directories. PHDs on XAN do carry a really significant enumeration load, especially because you don't have that server-side file tracking support. And ultimately, your metadata controllers become your bottleneck here. Also, just bear in mind that if you're gonna store homes on XAN, that this does not provide redundancy in your storage. You still need to have a backup plan for home directories that are stored on XAN.

Finally, some tips and tricks for hosting homes in an Active Directory environment. We talked earlier about the concept of defining that UNC name. And this generates two attributes in the AD plugin, the NFS Home Directory and the Home Directory attributes. Now this is--the NFS Home Directory path is always a POSIX path and it always starts at root. So on a server, it's /network/server/xserve.protenco.com, for example.

So when you define a home directory in Windows, there's only one attribute. There's not two like we have in Mac OS X. So you just have this native attribute called home directory, and it's a UNC path. No concept of the volume where the home directory share is located. So the AD plugin has to make an assumption. It has to assume that that share is on the root of the boot volume.

So the AD plugin actually does a little bit of magic for us here. It -- what it does is it looks at the Active Directory home directory, breaks in into parts, and then generates the two Mac attributes that we need. It generates the home directory attribute and the NFS home directory attribute.

However, it has to make an assumption. The assumption that it has to make is that the home share is on the root of the boot drive. Now, we know that in most of your environments, you're not hosting your home directories on the boot drive of your servers. You're hosting them on some sort of external volume or secondary volume. So the simple way to work around this is you create a symbolic link from root to the actual share where your home directories are being hosted.

What this does is it allows that path to be resolved appropriately. And what that means is that when you're hosting home directories for Active Directory users on an XServe, home directory auto creation works. You do not have to manually provision the home for each user. The home will be provisioned on the fly when the user first logs in via AFP or SMB. So at this point, I would like to bring up Greg Nagel, who's the Senior Systems Engineer for Walt Disney Animation Studios, to talk about a real-world implementation of Network Home Directories. Greg.

So, I'm Greg Nagel, Senior Systems Engineer for Walt Disney Animation Studios. We're located in Burbank, California. We've got about 900 artists and technicians, and we support a wide range of platforms. On the desktop, we have Linux, Mac OS, Windows. In the server room, we even have Solaris. There's probably a handful of Irix boxes around still. Isn't that a fantastic photo? Smog can look so beautiful when lit correctly.

So we have an existing infrastructure. Our directory services are hosted on Red Hat Directory Server. We have kick-ass NetApp appliances serving up our home directories. Very high availability, very high bandwidth. They work really well. And so our goals were to reuse that existing infrastructure. We didn't want to have to have a separate infrastructure for our Macs and a different one for our Linux boxes and a different one for our Windows boxes. We wanted them all to use the same thing.

We wanted to separate our user data from the machine. And we wanted to enable fast machine upgrades and swaps. We have an annoying tendency to buy the latest, greatest hardware for the most demanding artists and then take their hardware and move it down to less demanding artists and then take their hardware and move it down to administrative people and then take their hardware and move it down to me.

So we're moving machines around a lot, and it takes a lot of time. It's a heck of a lot easier if you don't have to worry too much about the user data on the machine. If that's somewhere else, then you can just swap out the machine. And also, many of our artists use both Linux and Macs to do their job. They might do some animation in Maya, but do some sort of painting in Photoshop. And so they need to be able to share data back and forth between the two platforms very easily.

So our first task in getting this all to work was to enable network accounts on OS X. And we were able to do that using the LDAP v3 plugin. And since we're using the standard RFC2-2307 UNIX mapping schema in LDAP, that's built in to the LDAP plugin. It's one of the pop-up menus.

You can just choose that and you can get your users and groups right out of LDAP. And if you're lucky in your organization, you may not have to do anything more than that. So what that allowed us then to do is the user could then log in using their existing UNIX short name and password.

Next thing we had to do, though, was get Network Home Directories and NFS shares working. Now, prior to Leopard, this was harder than it needed to be. Apple had a proprietary automounter that didn't work really like any other UNIX automounter out there. And so we weren't able to use our existing automount maps that we had in LDAP. We had to write scripts that took us a long time to write. We took those in and rewrote them out in a different format that the Mac OS X automounter liked.

The Mac OS X automounter mounted them in a strange place. And it didn't really work very well with laptops. If the laptop went off the network, back on the network, we had to do a lot of scripting to handle those situations. Leopard now includes AutoFS, and that's based on OpenSolaris' implementation of AutoFS. There's also AutoFS usually on most flavors of Linux. So if you are using an automounter on any other Unix-like platform, it's probably AutoFS.

Apples can get the automount maps from the directory services or local files, and with luck and a little work, it can use the exact same automount maps as other Unixes in your organization. And here's the big thing for laptops, is that it handles network transitions well, because it's tied in to directory services. If you boot up a laptop off the network but then plug it into your network, directory services sees that transition, queries LDAP for the automount maps, and brings the automounts up.

So, with AutoFS, you can now configure LDAP to talk to AutoFS simply by pointing it to the right stuff in your LDAP tree. There are some notes that you might want to be aware of. Out of the box, Apple wants to use what's called the AutoMount Map Schema. There are some older schemas. One that's in common use is called the NIS Map Schema.

So be aware of that. If you've got the NISMAP schema in LDAP, you may have to do some remapping or talk your LDAP admins into migrating to the newer schema. The map key in LDAP is asterisk. Now, that's always been traditionally the wildcard key is asterisk, but for some reason, older versions of Linux decided to use the slash as the wildcard key in LDAP. Well, the OS X Automata doesn't like that.

And the auto_mastermaps, the format's different. They differ somewhat. Just be aware that AutoFS 4 and earlier on Linux use a different format map than what everybody else uses. So if you've got AutoFS 4 machines, you may have to have a separate auto_mastermap for your OS X machines. So, we're now approaching network home nirvana. We have network accounts. We've got automated NFS home directories and shares.

And now our users can log in to any machine with the same credentials and get the exact same working environment and access the same data, no matter what machine they're on, no matter what platform they're on. But Nirvana's not what it's all cracked up to be. There are some challenges.

Since there's an existing home directory, we had configuration problems. The default preference is you can't use the user template, and so the default preferences aren't preset for people. So, we have to enforce quotas. We--that NetApp gear--very, very high performance, very, very high reliability, very, very expensive. So, we can't give everybody as much space on the NetApp as we could locally, so we have to enforce quotas. Caches. Local caching directs a lot of files to the network. There are some apps that don't perform that well on networks. And increasingly, mobile users.

So for default configuration, since it's a network home directory, it doesn't use the system library user template. Plus, that home directory pre-exists. It may have been used by a Linux user for other things, so we can't just blindly blow the directory away and copy a bunch of files there. So we have to have a way to set up sane defaults for the user the first time they log into OS X. And our solution was to write a custom app called the Disney Animation Setup Assistant. And I'd like to give a short demo. Or maybe not.

Let's skip the demo. Trust me, it's fantastic. If you're actually interested in seeing it, it's not important, Scott. If you're interested in seeing it, there is a lab later this afternoon on network home directories and portable home directories. I'd be happy to show it to anybody at the lab. So moving on.

Quotas were a challenge for us. The finder doesn't support or doesn't recognize NFS quotas. So users would fill up their network home. They really wouldn't know what they were doing. And suddenly, their apps would start crashing. The dock would reset to defaults. They'd call, and they didn't know what was going on.

So we needed to give them a way to know when they were approaching their quota. Once again, we wrote a custom app that just kind of sits down in the bottom corner of their screen and gives them how full their network home is and warns them as it gets fuller and fuller and fuller and then gives them what they should do as it gets full, which is usually to call somebody else to help them.

Adam Gerson has written an application that you can all download if you want to check one out. You also have the capability now, perhaps, of writing your own, because at least in our environment, the quota command actually returns something usable with our NFS home directories. It didn't before. I don't know if that's an improvement in Leopard or maybe it's a side effect of the AutoFS transition, but you can actually get decent information now.

The caches, which is where you've got cache files being stored out in the network. My recommendation now is to use MCX Redirector, as Scott showed earlier, and just remove those caches to a local path. And finally--actually, I said finally, but it's not finally--next, poorly performing apps. There's a lot of apps out there--less and less each day--but there's a lot of apps out there that really assume that the home is local, that the disk is right there, it's not over the network, and they're really optimized for that. And they don't really perform well when the home is out on the network and more limited bandwidth than you get from disk.

There's an application, Digidesigns Digidelivery. It won't even launch if the home is not on the local machine. I don't know how it would behave with an external account or on an external volume, but I do know that if it's out on network, it absolutely won't even launch. There are other apps that move a lot of data-- Photoshop, Final Cut, iMovie.

They're working with very large files, and obviously it takes more time to move large files over a network than it does to the local disk, and so they don't perform as well either. There's certainly a lot more. So what can you do? You want the benefits of the home directories and--or you want the benefits of network home directories and network accounts, but you want to give your users a good user experience.

So what you want to do is try portable home directories. You don't have to do these on laptops. You can do these on desktops as well. And what it'll do is move the data local to the machine, and so those apps that want local data are going to get it.

The final challenge with Network Home Directories was mobile users. Four or five years ago when we first started implementing Network Accounts and Home Directories, we only had a very small number of laptops. So we treated them as kind of one-offs. We just created local accounts on their machine and told people, hey, good luck with that, make sure you back stuff up, and you know.

And their passwords wouldn't be the same as their network password, and they would get really confused. And it was kind of a pain to manage. And then when Apple made the Intel transition, suddenly laptop use started to really accelerate. And this is, I think, because the performance of the laptops was on par with the desktop machines. They were really no longer second-class citizen in terms of performance.

Pricing is really good on laptops these days compared to desktop machines. And wireless has exploded, so you have a lot of benefit from working with a laptop because you can walk around the building, you can go to a conference room and bring your laptop with you. And so people want the laptops. In fact, we're only buying laptops and high-end Mac Pro machines. We don't buy anything in between. We don't buy any other desktops other than Mac Pros.

So local accounts are a pain to manage, local data is a pain to manage, so we moved to mobile accounts with portable home directories. This is how it works at Disney Animation. The mobile accounts are managed via MCX, Workgroup Manager. I'm sure you've seen it before. They're prompted to create the mobile account on their first login.

Admins can manually create mobile accounts, for example, for desktop users that might have applications that perform poorly. The laptop users, their home directories are protected by FileVault, and that's enforced via MCX. They don't have any choice over the matter. It just automatically is created when they first log in.

And so they get that new laptop, they log in with their network credentials, they're asked for the mobile account, they say yes, FileVault Home Directory is created, copy of the network, home is copied locally, and now the user has their data on their new machine. Almost no touching by a technician. In theory, you could hand them the machine and run as fast as you could to the other side of the room.

So, Apple, especially in Leopard, has made some really great default settings for home syncing, but there are some additional changes you might want to consider, certainly ones that we did. And our goals here were to not store unnecessary data on the server. We wanted to minimize the login and logout sync time, because the user just has to sit there and wait while that's happening. And we want to minimize the sync conflict dialogs that come up, because users don't know how to respond to them.

You know, say, "Do you want to keep this file or this file?" And sometimes they say, "Keep both." And when it's thousands of files and they've clicked "Keep both" and now they've blown out their network home directory because they've just doubled it in size, it gets really ugly.

So, one strategy that we went to was to exclude the big folders. We, by default, do not synchronize movies, music and pictures. Our thinking there is music folder, it's probably their iTunes music library. We don't want to back that up. We don't want to be responsible for that. That's their data. Movies, probably iMovie, iDVD stuff. Again, not stuff that we're using in production. Pictures, probably mostly iPhoto stuff. Stuff that we're not using in production. It's personal data.

But user education is critical here. You want to make sure they know that that stuff is not being synchronized to the network so they don't have a false sense of security. And so if that data is important to them, they can back it up elsewhere. Or if they're storing company data there, maybe they can decide to store it somewhere else.

A couple others. I think you should exclude the Downloads folder. I mean, they've downloaded it once from the Internet. They can download it again. There's some other ones: the Entourage Temp folder. Any time you get an iTunes software update, it puts the entire software image in your home folder. You don't need to synchronize that. Flash, the Downloads folder in Mail, and yet more.

This list up here comes from looking at--you'll see the file there. It's the standard exclusions plist. It's used by Time Machine when it decides what to back up. This is stuff that Time Machine says, "I don't need to back this up, so why should we synchronize it either?" So we're not gonna.

And this time I'm going to say finally, and I really do mean it. Finally, let's talk a little bit about forensics. So, if you want to know a little bit more about what's going on when there's a homesink, or maybe the homesink isn't doing what you expect, and you want to be able to investigate or troubleshoot, here's where you want to look.

There are log files in the user's local home--library logs, file sync agent, file sync agent, verbose. The sync state databases--this is what keeps track of what has synchronized in the past, so they know what things have been synchronized and what things haven't been synchronized yet. There are two places those are kept--one in the local home with the tilde and one out on the network home. If you delete both of those databases, the next time there's a synchronization, it'll act like it's brand new. It resets it right to the virgin state.

And the synchronization rules. There are local rules that are kept in the user's home folder in librarypreferences.com.apple/homesync.pl ist. And then, assuming that you are managing additional rules via MCX, an easy way to check to see what's actually being delivered to that machine or what that machine is paying attention to is use System Profiler, either via the GUI or via the command line. It now can show you the Manage Client settings, so you can see that, oh, what's being applied to this machine is what I think is supposed to be being applied to this machine.