I have not, although this shouldn't take a services engagement and doesn't address the root issue. This is functionality that existed up until 8.2.2, and continues if currently configured on such a host that is then upgraded to 8.2.3/8.3. It's on the same level of altered reality that the Cmode Snapdiff / IBM TSM support is currently hovering in.

Thomas Tomlinson Thomas.tomlinson@supervalu.commailto:Thomas.tomlinson@supervalu.com Desk: 208-685-8404 Cel: 208-991-3704

From: Ljungberg, Anders [mailto:Anders.Ljungberg@netapp.com] Sent: Friday, February 27, 2015 11:44 AM To: Tomlinson, Thomas; toasters@teaparty.net Subject: Re: cluster mode 8.2.3 / 8.3 dynamic home directory change

Hi Thomas,

Have you explored the UTM (Unified Transition Methodology) with your NetApp or NetApp Partner team?

Many Thanks Anders Ljungberg Sr. Director Enterprise Transformation and Operations & Advanced Consulting Services EMEA NetApp +44(0)208 756 6785 Direct +44(0)7730437939 Mobile +14084821148 US Mobile anders@netapp.com mailto:anders@netapp.com [Insight 2014]http://www.netapp-insight.com/?ref_source=ad-ins--16283

From: <Tomlinson>, Thomas <Thomas.Tomlinson@supervalu.commailto:Thomas.Tomlinson@supervalu.com> Date: Friday, 27 February 2015 10:19 To: "toasters@teaparty.netmailto:toasters@teaparty.net" <toasters@teaparty.netmailto:toasters@teaparty.net> Subject: cluster mode 8.2.3 / 8.3 dynamic home directory change

Hi Toasters,

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. Currently we make extensive use of the traditional static 7mode home directory share, cifs.homedir (\filername\cifs.homedirfile:///\\filername\cifs.homedir). This is further referenced behind DFS as a single link name with multiple targets. It works great, allows for all users to have a static username defined in AD, allows migration of filers without massive user updates, DR, etc. So life is good, or as good as it can be managing windows home directories.

We're now slowly staring to lifecycle 7mode clusters to cmode, which has had a few hiccups, but I expected that . Prior to 8.2.3, you can replicate 7mode home directory functionality perfectly, even making up whatever static name you want. Fast forward to just recently when I was configuring a small cluster at a remote location. 8.2.3, sure slap that on. Configure the dynamic home directories, sure,errr.... no. A seemingly innocent entry in the release notes for 8.2.3 states that static names are no longer acceptable. A previously configured static share is brought forward and continues to function but you can no longer create new ones. Any new dynamic home share has to have the username in it (%w or %u).

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. Is anyone else similarly affected by this? I'm struggling to understand what twisted logic guided this coding decision.

Thomas Tomlinson Thomas.tomlinson@supervalu.commailto:Thomas.tomlinson@supervalu.com Desk: 208-685-8404 Cel: 208-991-3704

Today I hit KB 2011961 (https://kb.netapp.com/support/index?page=content&id=2021961&actp=SUB...)

It is for 7-Mode, and it says

When upgrading Data ONTAP to 8.2.2 on 7-Mode, directories stop working with \filer~<file:///\%5C%5Cfiler%5C%7E%5C> or \filer\cifs.homedir<file:///\%5C%5Cfiler%5Ccifs.homedir%5C> .However, directories work with \filer<usernamefile:///\\%5C%5Cfiler%5C%3Cusername>. Data ONTAP 8.2.2 introduced a new option 'cifs.home_dir.generic_share_access_level.'

When this option is set to 1, access using the generic home directory share name is always allowed. Set this option to 1, if you are sure there is no possibility of more than one user on the same client accessing the generic home directory, share at the same time.

I wonder if C-Mode has equivalent of this option.

From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of tmac Sent: Wednesday, March 04, 2015 7:04 PM To: Tomlinson, Thomas Cc: toasters@teaparty.net Subject: Re: cluster mode 8.2.3 / 8.3 dynamic home directory change

Hey all,

I've recently discovered that the static homedirs were disabled due to a bug with a public report: 780969http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=780969

HOMEDIRs can be used in a couple of ways and static is one of them. A new feature in Windows 7 (SMB2.1) called File Lock Lease no longer allows the client to handle the static HOMEDIR correctly (especially so when using VDI or Terminal Services). Basically, if two users who happen to have the same file name in their respective home directory, they could gain access of each other’s file.

This concerns engineering (obviously a security issue) and there is no straight-forward way to make Windows 7 behave correctly. It was decided to disable this feature in cDOT. More and more customers are turning to cDOT and engineering is being more aggressive towards this release.

Note however, the same vulnerability exists in 7-mode also. In 7-mode, though, the feature is not disabled and an EMS message is sent to let an admin disable the feature on their own.

If anyone would like to comment, please do. I will make sure any appropriate comments and concerns get back to engineering.

--tmac

Tim McCarthy Principal Consultant 443-228-TMAC (Google Voice) 214-279-3926 (eFAX)

[http://dl.dropbox.com/u/6874230/na_cert_dma_2c.jpg] [http://dl.dropbox.com/u/6874230/rhce.jpeg] [http://dl.dropbox.com/u/6874230/na_cert_ie-san_2c.jpg]

Clustered ONTAP Clustered ONTAP NCDA ID: XK7R3GEKC1QQ2LVD RHCE6 110-107-141https://www.redhat.com/wapps/training/certification/verify.html?certNumber=110-107-141&isSearch=False&verify=Verify NCSIE ID: C14QPHE21FR4YWD4 Expires: 27 October 2016 Current until Aug 02, 2016 Expires: 29 October 2016

On Fri, Feb 27, 2015 at 2:22 PM, Tomlinson, Thomas <Thomas.Tomlinson@supervalu.commailto:Thomas.Tomlinson@supervalu.com> wrote: I have not, although this shouldn’t take a services engagement and doesn’t address the root issue. This is functionality that existed up until 8.2.2, and continues if currently configured on such a host that is then upgraded to 8.2.3/8.3. It’s on the same level of altered reality that the Cmode Snapdiff / IBM TSM support is currently hovering in.

Thomas Tomlinson Thomas.tomlinson@supervalu.commailto:Thomas.tomlinson@supervalu.com Desk: 208-685-8404tel:208-685-8404 Cel: 208-991-3704tel:208-991-3704

From: Ljungberg, Anders [mailto:Anders.Ljungberg@netapp.commailto:Anders.Ljungberg@netapp.com] Sent: Friday, February 27, 2015 11:44 AM To: Tomlinson, Thomas; toasters@teaparty.netmailto:toasters@teaparty.net Subject: Re: cluster mode 8.2.3 / 8.3 dynamic home directory change

Hi Thomas,

Have you explored the UTM (Unified Transition Methodology) with your NetApp or NetApp Partner team?

Many Thanks Anders Ljungberg Sr. Director Enterprise Transformation and Operations & Advanced Consulting Services EMEA NetApp +44(0)208 756 6785tel:%2B44%280%29208%20756%206785 Direct +44(0)7730437939tel:%2B44%280%297730437939 Mobile +14084821148tel:%2B14084821148 US Mobile anders@netapp.com mailto:anders@netapp.com [cid:image001.png@01D0B325.A4F55DD0]http://www.netapp-insight.com/?ref_source=ad-ins--16283

From: <Tomlinson>, Thomas <Thomas.Tomlinson@supervalu.commailto:Thomas.Tomlinson@supervalu.com> Date: Friday, 27 February 2015 10:19 To: "toasters@teaparty.netmailto:toasters@teaparty.net" <toasters@teaparty.netmailto:toasters@teaparty.net> Subject: cluster mode 8.2.3 / 8.3 dynamic home directory change

Hi Toasters,

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. Currently we make extensive use of the traditional static 7mode home directory share, cifs.homedir (\filername\cifs.homedirfile:///\\filername\cifs.homedir). This is further referenced behind DFS as a single link name with multiple targets. It works great, allows for all users to have a static username defined in AD, allows migration of filers without massive user updates, DR, etc. So life is good, or as good as it can be managing windows home directories.

We’re now slowly staring to lifecycle 7mode clusters to cmode, which has had a few hiccups, but I expected that . Prior to 8.2.3, you can replicate 7mode home directory functionality perfectly, even making up whatever static name you want. Fast forward to just recently when I was configuring a small cluster at a remote location. 8.2.3, sure slap that on. Configure the dynamic home directories, sure,errr…. no. A seemingly innocent entry in the release notes for 8.2.3 states that static names are no longer acceptable. A previously configured static share is brought forward and continues to function but you can no longer create new ones. Any new dynamic home share has to have the username in it (%w or %u).

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. Is anyone else similarly affected by this? I’m struggling to understand what twisted logic guided this coding decision.

Thomas Tomlinson Thomas.tomlinson@supervalu.commailto:Thomas.tomlinson@supervalu.com Desk: 208-685-8404tel:208-685-8404 Cel: 208-991-3704tel:208-991-3704

_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

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 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\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.