What the heck am I talking about? Well, its the lesser-used NetApp ONTAP homedir feature. What the heck does it do? Make home directory provisioning, configuration and management so much simpler!
So, that's a pretty bold blanket statement, but the benefits of using the homedir feature in ONTAP is just so overwhelming, there's really no downside (besides the initial configuration and user provisioning process modification) to enabling and using it. In essence, it's really a best practice when using ONTAP for home directory serving.
What is this homedir function you talk about? Well it's a feature in ONTAP that created shares and exports on the fly based on the client's usernames that are presented to ONTAP during the mount or drive map process. This makes it so much easier to provision users, home directories, permissions, quotas, and everything in between. Take the guess work out of it all!
Does it help?
Yes! There is actually a recent Microsoft Windows bug rolling around in build 1803 that can cause some performance issues. When you use that pesky little search bar in Windows Explorer and search a mapped drive, and that mapped drive is actually a folder within an actual share, then Windows does some real deep searching all the way back to the root of the share. WHAAA??? There are other stupid things happening with the Windows clients too that can cause some weird performance issues when there is a lot of file enumeration going on. Most of this client behavior is happening on the home drive, or even worse, a roaming profile drive. This is because when you create a home directory share, you create a single folder, share that folder, create everyone's home directory off that folder, then have the users map the folder level. (something like mapping H: to \\server\homedirfolder\username). No I'm not going to get into the minutia of the behavior since MS has done some work to fix it, but it's there nonetheless. Let's all use this awesome ONTAP feature to mitigate these issues.
Do I really need to know how it works?
Maybe. It's actually not that complicated. When a user connects to the "homedir", ONTAP just looks into a few volumes specified for that user's name on a directory and then creates a hidden share on the fly and lets the user attach to it. That's it. It's that simple. Nothing more, nothing less.
Why do I want it?
There's a few things that make this so much more simple than the traditional way of creating a "homedir" share and mapping sub-directories to it.
First of all, it's simpler to expand. What if the volume serving your homedir is full? What if it needs more performance? What if we need to create more volumes? Split it up? You can see the problems there. Let me give you a quick demo.
Let's just add the volume to the search path....
That was easy! As long as all the homedir volumes are in the same SVM, then you can add as many volumes as you want to the search path.
Why else do I want this? Well, the only thing you have to do when provisioning a new user is to create the user's homedir folder in one of the volumes of the search path. No need to create a new share... no need to create a new volume.... no need to do anything else except create the folder and apply the permissions! You can even automate this with PowerShell! You can even balance the amount of homedirs in each volume with the PowerShell script!!!!
I'm Sold! How do I implement this?
It's easy. Just create the homedir share and add volumes to the search path. With System manager... its an all-in-one process!!!
Here's where you can get creative.
For the name, this is what you will be putting into AD for the home dir path. There is a caveat though. If you create a non-unique name and have more than 1 user log into a machine at the same time, then there can be issues. Why? MUP cache. What??? Yes. I said MUP cache. What in the blazes is that? Well, when the client mounts the home directory (let's just call it \\svm\cifshomedir), what is going on under the covers is some DFS magic to actually point it in the right direction. The clients cache this DFS magic. Unfortunately, that caching happens at the machine level. So when user jimbobbillyjo logs into the Windows machine and has their homedrive connected, then the client machine's DFS cache says that \\svm\cifshomedir is actually \\svm\jimbobbillyjo$. Now when user georgemcf logs into the same machine (like with a user switch) then when it tries to map \\svm\cifshomedir, then it's actually trying to mount \\svm\jimbobbillyjo$. That won't work for poor georgemcf.
In order to just bypass all that nonsense, use the appropriate abbreviation in the name. %w will be the most common, then you can use %username% in the drive mapping in AD.
So what do I need for AD?
Just set up the homedir. There are several schools of thought.
* Home Folder: This is the most obvious. ADUC gives you a drive letter and path. This will also give you some variables once logged in like %HOMEDRIVE%, %HOMEPATH% and %HOMESHARE% that you can use to do more with.
For automation, you can use variables. I would use \\svm-name\%username%. Then ADUC will translate that to username.
* Roaming Profile: Its the exact same as the Home Folder above, but its called the Profile path in ADUC.
* GPO for mapped drives: This is more of a fan favorite. No need to set something for every computer account. If this is a domain-wide GPO, then everyone gets the drive mapped. This is where you need to use the variables though.
The downside? You don't get any of the cute variables.
Thank you for this information, exactly what I was looking for, more useful than a lot of the NetApp documentation, and thanks for the %username% tip!
ReplyDelete