Here’s a little more about how the dynamic share name change affects DFS.
Today, we have a single DFS link within our namespace for home directories. \DOMAIN\DFSNAMESPACE\HOME_NAS\autohomefile:///\\DOMAIN\DFSNAMESPACE\HOME_NAS\autohome. This link has multiple targets, all referencing the 7mode static cifs.homedir
\filer1\cifs.homefile:///\\filer1\cifs.homedir \filer2\cifs.homedirfile:///\\filer2\cifs.homedir \filerinotherdatacenter\cifs.homedirfile:///\\filerinotherdatacenter\cifs.homedir
Works great, every user has a the same home directory, no confusion, life is grand.
Now being forced to use a completely unique share name for each user, it makes masking this behind a single DFS link impossible. I’ve tried all the combos I can think of and nothing works.
Let’s use the simplest form, just the username. The share looks like this:
winhomevserver %w %w homedirectory Everyone / Full Control - Say my username is tomtom. I could access the share directly like this:
\winhomevserver\tomtomfile:///\\winhomevserver\tomtom \winhomevserver%USERNAME%file:///\\winhomevserver\%25USERNAME%25
The first one is doesn’t help us much, but the username variable has promise. Perhaps we can put that in DFS? Sadly this doesn’t work. You can certainly create a target with that UNC name but it doesn’t work. The service (mup) that translates targets for a DFS link attempts to translates that variable. Of course that runs as the system ID which doesn’t have a clue what the user’s %USERNAME% is.
I thought perhaps we could just reference the vserver behind DFS, for example a target of \winhomevserver<file:///\winhomevserver> for the DFS link. Then we could reference the username after that, like \domain\dfsnamespace\home_nas\autohome\tomtomfile:///\\domain\dfsnamespace\home_nas\autohome\tomtom. Unfortunately this violates DFS rules which require a valid UNC of \servername\sharenamefile:///\\servername\sharename (missing the sharename portion here).
How about masking everything behind a directory, such as \winhomevserver\home%wfile:///\\winhomevserver\home\%25w? That might allow us to reference a static UNC name in DFS and pass the username as part of the path.
Works great in DFS, doesn’t work in cmode. This violates the rules for a share name as they can’t have back slashes.
nas001::> cifs share create -vserver winhomevserver -share-name home%w
Error: "home%w" is an invalid value for field "-share-name <Share>"
pnas001::> cifs share create -vserver winhomevserver -share-name home%w
Error: "home%w" is an invalid value for field "-share-name <Share>" nas001::> cifs share create -vserver winhomevserver -share-name home\%w
Error: "home\%w" is an invalid value for field "-share-name <Share>" nas001::> cifs share create -vserver winhomevserver -share-name home%%w
Error: "home%%w" is an invalid value for field "-share-name <Share>" nas001::> cifs share create -vserver winhomevserver -share-name home\%%w
Error: "home\%%w" is an invalid value for field "-share-name <Share>" nas001::> cifs share create -vserver winhomevserver -share-name "home\%%w"
Error: "home\%%w" is an invalid value for field "-share-name <Share>"
nas001::> cifs share create -vserver winhomevserver -share-name 'home%w'
Error: "'home%w'" is an invalid value for field "-share-name <Share>" nas001::> cifs share create -vserver winhomevserver -share-name 'home%w'
Trying to embed a static portion of the name has the reverse problem. Say we create the home share like this ”home_%w”. I could access it directly as \winhomevserver \home_tomtom or \winhomevserver\home_%USERNAME%file:///\\winhomevserver\home_%25USERNAME%25. But then how to reference this behnd DFS? You can’t. There’s no way to reference a partial share name and have the client complete it with a unique string in the request. Everything appending to the DFS query end up with a back slash in it after the sharename defined in the DFS target.
As far as I can tell, without a static share name, there’s no way to reference the home directory through DFS with a single link. Sure I could create 5000 individual DFS links for each user, but at that point why even bother. I might as well just use the direct UNC to the filer.
Thomas Tomlinson Thomas.tomlinson@supervalu.commailto:Thomas.tomlinson@supervalu.com Desk: 208-685-8404 Cel: 208-991-3704
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Borzenkov, Andrei Sent: Friday, March 06, 2015 2:05 AM To: Rhodes, Richard L.; toasters@teaparty.net Subject: RE: cluster mode 8.2.3 / 8.3 dynamic home directory change
To be honest, I do not quite understand how this Data ONTAP change would impact described workflow.
Basically what your friend says, there is a DFS mapping for every user from fixed string \server1\share1\path1file:///\\server1\share1\path1 to variable string \server2\share2\path2file:///\\server2\share2\path2 for every user. At this point \server2\share2\path2file:///\\server2\share2\path2 must obviously be different and unique for each user. Or do I miss something?
Workflow that would be impacted is when you do not use DFS at all and use fixed string to map share that would be internally “redirected” by Data ONTAP depending on which user is connected. But that does not sound like the case your friend has described.
From: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Rhodes, Richard L. Sent: Thursday, March 05, 2015 6:57 PM To: toasters@teaparty.netmailto:toasters@teaparty.net Subject: RE: cluster mode 8.2.3 / 8.3 dynamic home directory change
I’ve followed this thread with much interest.
Our NAS environment is currently a whole bunch of Windows servers (AD, DFS) that support home dir shares and large shares for “stuff”. Later this year we may look at converting from Windows servers to a NAS vendor appliance (Netapp, EMC, whomever). We currently have NetApp systems (8.1.2 7mode) for a document mgt system (FCP and CIFS). The CIFS portion consists of about 25 CIFS shares to a couple Windows server. This is nothing like our Windows NAS environment.
Thomas said:
I just stumbled upon a change in 8.2.3/8.3 with respectto the dynamic home shares and curious to get other folks views on it.
<snip>
A seemingly innocent entry in the release notes for 8.2.3 states that static names are no longer acceptable. Any new dynamic home share has to have the username in it (%w or %u).
<snip>
Needless to say this is a major change to our environment.Automation changes, massive AD updates (close to a nightmare with our IT organization) and a complete invalidation of our DFS namespace structure for home directories. Thomas Tomlinson
I don’t really understand all this, so I asked a friend who works with the Windows servers, AD, and DFS. I forwarded him Thomas’ email for his comments. Much of my friends comments go over my head, but it sounds like we would have to make massive AD changes to use NetApp systems.
My Friends comments are below. While asking a lot, Is there someone out there who could read these comments from my friend and translate into what it would take to convert from our existing Windows NAS environment to Netapp?
Hi Rick,
I’m not sure about the ‘dynamic’ vs ‘static’ terminology that is being used here, but what he may be referring to is the ability to use a variable in the home directory path that is set as an attribute of the active directory user object.
For example on my active directory user object there is the attribute homeDirectory that has the value \xxxx.com\home\pdc7\yyyyfile:///\\xxxx.com\home\pdc7\yyyy, and another attribute homeDrive that has the value H. The path that is \xxxxx.com\home\pdc7file:///\\fenetwork.com\home\pdc7 is a Distributed File System (DFS) ‘target’ – basically a shortcut to a windows server and share, which in this case is the server WISF12P and the windows ‘share’ on it is HOME7. Then in that share there is a folder by the name of yyyy which is my home directory and when I logon to a Windows machine it will map H to that path.
What DFS allows us to do is ‘publish’ out this logical path in a way that never has to change – we can move the data around and change out the underlying servers and shares just by changing the pointers – the data in AD does not need to change. Thomas references this flexibility in his email.
But what would also be possible is for us to use a variable like %username% in the homeDirectory attribute. In my case it would be \xxxx.com\home\pdc7%username%file:///\\xxxx.com\home\pdc7\%25username%25. As long as there was a folder in that windows share that matched my Active Directory username, and I had the necessary permissions to it, the map to H on logon would be successful. As he noted making the change from a ‘static’ username in all our AD objects to a variable would be fairly significant – there is the data manipulation that would need to take place as well as modifying the way that home directories are provisioned when new users are created.
I’m puzzled by why the underlying storage system would care though. DFS will work regardless of what is sitting under \xxxx.com\home\pdc7file:///\\xxxx.com\home\pdc7, as long as the windows machine has an appropriate client to access it. We even tested it with Novell servers as the ‘server’ and ‘share’ that the DFS path pointed to – as long as the Novell client was installed on the machine the map would work.
Hope this helps! Tony
Thanks!
Rick
________________________________ ________________________________
The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message.