Windows 7 logon script net use fails

Question

Our network PCs currently consists of Windows XP Professional on a mixed 2008/2003 domain, with exception to one machine, which is a new Windows 7 PC we have bought for testing before we deploy the operating system. But we have discovered a problem with our logon script which automatically maps network drives for our users.

The logon scripts are done via User GPOs, but the script itself is just a .cmd file using net use.

The permissions are perfectly fine, as the same user can log on to a Windows XP machine and get their drives mapped without problem, but this one drive mapping constantly fails.

This is repeatable using the net use command, and fails every time - it actually prompts the user for a username and password when executed interactively, yet if we enter \\server\share from a run dialog, the contents of the network share appear and are accessible without any further authentication.

The Windows 7 PC (just like the XP systems) are domain members and the account being used is a domain account, which does have access to the share (as stated, it works fine on XP).

I fail to understand what is happening here, as other shares on the server get mapped on the Windows 7 system.

More info:

The effective permissions of the share in question only grant the user 'list' permission on the root directory, the share permissions are 'everyone,full control'. I've created a new share with the same permissions just to test if it was down to the 'list' permissions on the root directory, but the Windows 7 machine maps this one fine.

Edit: If I grant the user 'read' NTFS permission on the folder at the root of the share, then the share maps fine, but take away read (i.e. back to list only), then the drive mapping fails again. Unfortunately, granting 'read' at this level isn't an option.

Further Edit: (See my comment to ITHedgeHog's answer). This drive mapping is failing no matter how I try with what appears to be a simple 'access denied' error, however the strange this is that the user can browse the share if they type the UNC path into an explorer window. I think that this must be something to do with 'list folder' permission.

Solution 1

Comparing the permissions of the drive mapping that worked, to the one that didn't, I found that if I looked at the advanced view of the permissions, that the share that worked actually had the following permissions on the directory (only):

• Traverse Folder / Execute File
• List Folder / Read Data
• Read Attributes
• Read Extended Attributes
• Read Permissions

Whereas the mapping that didn't work, only granted the following permissions on the directory.

• List Folder / Read Data

Adding the other four permissions resolved the problem.

Strangely, the basic view of the permissions both showed 'List Folder Contents', which is what threw me, as I thought that if the fine-grained permissions were non-standard, that the basic permissions would show 'special'.

Solution 2

I presume a mixed 2008/2003 domain indicates you are running at least one Windows 2008 DC? If so editing group policies from that machine should allow you to map a drive under the user preferences section of group policy.

This is how we have managed to deploy mapped drives to Windows 7 clients.

More information: http://blogs.technet.com/b/grouppolicy/archive/2009/02/11/gp-preferences-will-reduce-logon-scripts-mapping-drives.aspx

Solution 3

Is the user in the administrators group on the Windows 7 box? Can you try removing the user from the admin group? Or temporarily disable the UAC and see if things work.

There are some cases where the UAC will interfere with login scripts.

See the section 'Group Policy Scripts can fail due to User Account Control' on this page. http://technet.microsoft.com/en-us/library/cc766208(WS.10).aspx

Comments

[Kcmamu]

They are both owned by the administrator that created the shares, but this shouldn't make any difference, as we are talking about a share that is available to all users, not a roaming profile or home directory share.

[Kcmamu]

No, the user is not an administrator either on the PC or the domain. The user account is just a standard user account.

[Zoredache]

No disabling UAC isn't the long term answer, see the MS document.

[Kcmamu]

Unfortunately the batch file still fails at the same point, in the same way.

[Kcmamu]

Thanks. I had considered this, but I've also had a bad experience using these under Windows XP (very slow logons with Windows XP that turned out to be down to printer GPO preferences). I could of course restrict the policy using WMI filtering so that only Windows 7 clients pick up this policy, and continue as we do for Windows XP

[ITHedgeHog]

You could restrict it through WMI, however our experiences have been good - it hasn't caused slow logins on XP Machines. Do you have a small group of XP Machines you could test the GPO on?

[Kcmamu]

Having just tried this, Group Policy Results shows that the mapping of this share via GPO preferences is attempted, but returns with an error code of 0x80070005 (Access Denied?). All other mappings via GPO preferences work fine.

[ITHedgeHog]

Were the drives mapped previously before applying the GPO? It may be worth disabling the GPO clearing the drive mappings that exist, rebooting the machine and then reapplying the GPO.