2010-07-12 07:49 AM
Just thought I'd pop this up and see if anyone else is getting this same issue as I'm currently out of ideas.....
We have a special vb script that runs on all our workstations (Windows XP and Vista) which's logs some vital information to a file on the filer once the worksation starts up and before the users login. I have now been asked to make sure that our new image (Windows 7) also reports this information.
Currently to perform this task, I have a GPO which runs the vb script on the workstation. It is called within the GPO -Startup/Scripts/Windows Settings/Computer Configuration. No problems so far.
The script outputs the values to the log file on the san, the rights to this file are set as READ,WRITE and EXECUTE for the DOMAIN COMPUTERS group. This is where the trouble starts.....
All Windows XP and Vista machines appear fine, Windows 7 workstations appear not to have access rights even though I've checked the workstations and they are in the Domain Computers group.
The scripts is working fine via GPO on the Windows 7 boxes as if I change the log file path to the local C: drive, but fails on the SAN
Any ideas, have a missed something?
2010-07-12 12:31 PM
This KB article may address your issue. Windows Server 2008 R2 or Windows 7 clients connecting to a filer share fail
I also thought this article might be of relevance either now or in the near future since you're running Windows 7.
2010-07-13 01:00 AM
Luckily, I already spotted the snapshot issues with SMB and put SMB2 into place a while ago.
The GPO edit on the NTLM settings hasn't made any difference. I've just ran the script on a scheduled Tasks startup using a userid/password and that worked.
If I can't find a fix then I guess I'll have to do it that way.
2010-07-13 04:19 AM
hi, this sounds quite interesting.. just wondering are you able to access the SAN share from a windows 7 host, once you have logged on ok ?
Have you tried giving the computer account FULL control of the file on the SAN at all.
Also are any error messages logged in the event logs for your windows 7 host.
From the previous posts, it does look like an issue with Windows7, its just narrowing it down!
2010-07-13 07:06 AM
once I've logged onto the Windows 7 workstation is is fine (as it's using the user accounts security details rather than the Domain Computer account).
I've tried full control to the domain computers group without success and now I'm going to try and use the EVERYONE group, not what I want be may prove that it's possible.
I've got a gut feeling it's going to be something MS has changed in the local security policies by default, most of this kind of hassle I get is normally one or two MS oftions that changed such as NTLM, etc.
P.S can't see anything in the event log or on the filer system messages.
2010-07-14 01:14 AM
Just to keep you updated...
Well, after try the everyone group I 'm still getting the same issue, the Domain Computers workstations group permissions don't seem to be applying on the Netapp filer.
I decided to set the same permissions on a W2K3 server (Domain Computers Full Rights as my test on the SAN) and that worked. Hmmm, why are XP machines okay and not Windows 7?
2010-07-26 02:04 PM
Has anyone got an update to this? Im getting Access Denied messages when applying NTFS Permissions to a CIFS Share.. Take a look at my attached screenshots. But, with applying them from a Windows 2003 machine, the permissions apply without all the access deny messages!
2010-08-05 07:39 AM
looks like a slightly different issue then the one I have. All my security rights are added to the CIFS shared without issue but workstation (that's haven't logged in) don't appear to have the file rights even though I've used the Domain Computers group object.
Could it be something different with SMB 2.5 and Netapp Filer using SMB2.0?
2010-11-17 11:39 PM
We solved it, kind of!
Our solution was to use the pure IP address or DNS host record of one of the VIF's on the filer in our scripts rather than an DNS Alias record with pointed to our filers many vifs.
DNS alias record "data.domain.uk" would resolved to filerA-vif1.domain.uk and filerA-vif2.domain.uk host records.
We were under the impression that if vif1 went down, because all scripts point to data.domain.uk then this would still resolve but to the vif2 interface.
It appeared to work fine under previous versions of Windows but Win 7 didn't like it at all, as soon as the host address filerA-vif1.domain.uk was added to the script and the alias removed all was well.
Hope this helps,