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 respect

>to 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\yyyy, and another

>attribute homeDrive that has the value H. The path that

>is \\xxxxx.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%. 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\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