Ever since installing the Windows 7 RTM build, I have been unable to have that system automatically log on to an assigned mapped drive on my MacBook.
Until now.
The basic concept is that from Windows Explorer, you want to map a networked drive, and retain that mapped network drive so that it is persistent through multiple reboots and logins to that system. The problem is that the default installation of Windows 7 appears to support this feature (as happens quite seamlessly in XP), but in fact it doesn’t.
When you log on to a network volume and assign it as a mapped drive, there is a “Remember my credentials” checkbox on the login dialog. One would expect that this should add the login credentials to the Credentials Manager, so that the details are retained and you can automatically log in to that mapped drive the next (and every subsequent) time that you restart the Windows 7 system.
Entering credentials
Why else would you want to check the “Remember my credentials” checkbox, right?
Unfortunately, that isn’t how it happened for me, and every time I rebooted the system, I would see a message balloon pop up in the taskbar, and the mapped drive would contain a red X through it, indicating that the drive mapping could not be re-established.
Mapped drive is not connected
When I mapped the drive, this process had created a record in the Windows 7 Credential Manager, but this showed that the persistence of the login to the networked drive was just for the current session. This did not seem to me to be correct. Manually creating a record in the Credentials Manager also failed to rectify the problem.
After quite a good deal of research, I discovered that the actual source of the problem has nothing to do with the Credentials Manager, but instead relates to how the default group policies for SMB shares are set up when Windows 7 is installed. The default value is that the relevant policy is left unset, and that creates this problem when you wish to automatically log in to some SMB shares. This of course is how OS X drives are seen by Windows when they are set as mapped drives within your system, and that is why this problem seems to occur.
Fixing the problem requires editing the group policies. Not a difficult task, but it does entail changing some registry settings. If you are not comfortable with doing getting your hands dirty in the registry, stop now, or find someone who can do this. And be sure that you back up your registry before you start. If you screw up your registry, you might not be able to restart and use your system, so consider yourself warned.
To edit the Group Policies, we need to run the Group Policy Editor program. Press the Windows and R keys together to bring up the Run Program dialog, and then, in the Run dialog, enter gpedit.msc and press the OK button.
After a few moments the Group Policies Editor will open.
In the Group Policies Editor, open each of the following items in turn:
Computer Configuration
Windows Settings
Security Settings
Local Policies
Security Options
Now, right-click on the “Network security: LAN Manager authentication level” policy item, and then, from the context (pop-up) menu, select “Properties”.
Now select the “Local Security Settings” tab, and then, in the dropdown box, locate and select “Send LM & NTLM – user NTLMv2 session security if negotiated”.
Now click the OK button, and then finally, you may close the Group Policies Editor window.
The problem should now be fixed, and your mapped drive logins should now be persistent through multiple reboots of the system.
Oh my gosh… THANK YOU! THANK YOU! THANK YOU! I only wish it wouldn’t have taken me 4 hours to find this post.
Mega Awesome – thanks!
Just registered to say THANK YOU THANK YOU THANK YOU!
You are great! Thanks for sharing
This didn’t work for me. I’ve tried the credentials manager and this fix with no luck. I really wish I could figure this out.
Many thanks, worked like a charm.
Thank you so much!
I also had to disable Kerberos auth for SMB on my OSX Server for this to work.
It didn’t work for me…
This didn’t work for me – Win 7 Pro. I solved my problem using the “Credential Manager. To open the Credential Manager and add a Windows credential:
1. Click Start and click Control Panel.
2. Click Credential Manager.
3. Click Add a Windows credential.
4. Within the Resource field, type in the name of the resource (such as the computer name) or the URL of the Web site you want to access.
5. In the User name field, type in your username used to access the resource or Web site.
6. In the Password field, type in the password used to access the resource or Web site.
7. Click OK.
The credentials are now stored within the Windows Vault. You can use Credential Manager to edit or remove credentials from the vault at any time. In addition to adding Windows Credentials, you can add certificate-based credentials and generic credentials.”
In which case, you actually had a different, but more benign problem. If you will read my post, you may observe that the Credentials Manager had already been tried and failed, and thus a different approach was required.
You might also note that this post is actually entitled “Fixing the Mapped Drive Credentials Problem”, and thus I think that people might reasonably look to this solution after they’ve actually experienced an issue within the Credentials Manager.
FYI, this may be why the group policies editor will not load and you will not be able to connect to a NAS or shared folder on the network without re-entering username and password after a restart.I found that this will not work on Windows 7 starter or home premium, in other words you will need to upgrade for this feature to be turned on.
fmeneghini:
Wouldn’t this potentially cause lockout issues when user network passwords change? I’m imagining this to be the case. Any suggestions for Enterprise environments?
I have been fighting this same problem for a long time as well. I finally found the solution that worked for me at least.
1 Open Credential Manager.
2 Edit the name to include the name of the server connection. For example.. Server\Username
3 save the password
4 reboot and test
But Roger, (and as I’ve already pointed out) you are addressing a different issue, and that issue – with your solution – is exactly the one that my original post addresses when your suggestion has actually failed. You’re at milestone 7; this post has already passed that point, and moved on further up the road.
Thanks, Gary. This worked for me and I appreciate your help.
Larry,
Glad to help.
omg it worked! you are amazing dude. the credentials manager didnt work for me either. I had to login manually with all my windows 7 PC’s since i got my NAS at the start of the year (it wasn’t a problem with Vista).
I just have one problem now… I can’t access gpedit.msc on a PC using Windows 7 Home edition. It works on the Windows 7 Ultimate edition only.
worked. thanks so much.. another question.. I have the same problem in XP. How to I get to those same settings?
In XP the problem might seem to be the same, but it would be likely to be from a different cause.
o. ok.
I have tried both, the credentials manager and this post, neither has worked for me, but I have an odd situation in that I need to connect to resources in multiple domains. The credentials manager works great until you reboot. Then, Win7 seems to do a bit of it’s own housecleaning and any entries in the credentials manager that are in the SAME domain as the computer are removed. The entries for the second domain remain ans work fine. I have validated this by moving the computer in and out of both domains. When in domain A, the creds for A are removed and the creds for B remain, when the computer is in domain B, the creds for B are removed and the creds for A remain. I need them BOTH to stay on reboot. My persistence is set to Enterprise and I cant find a way to change that. Any and all suggestions are welcome, and TIA.
Well, I think I spoke too soon. I had the creds for both domains configured, did the fix in this post, re-booted, and the creds for my current domain were gone so I thought the fix did not work. Then I thought maybe one more try adding the creds after the fix was in place, added all the creds, re-booted(twice actually) and both times ALL the creds stuck. So, THANK YOU for the fix Gary!
Glad to be able to help.
Thank you so much for this! Everyone kept telling me that the Credential Manager would solve my (Win7) -> (mapped drive in Mac OS X) problem, but nothing worked. Your solution has me connecting to the mapped drive every time, with the credentials remembered. That’s one nagging frustration removed… many thanks!
We’re thrilled that it worked for you.
Take care.
You have NO idea how much I appreciate this.. Well… maybe you do.
For msome reason I do not see the “Network security: LAN Manager authentication level” policy item as a choice. My computer is not a member of the domain, but I access domain resources.
Please ignore my previous message; I realized what I did wrong; it’s all good! Thank you for your expertise.
Our pleasure.
Cheers
Solution for home premium users:
http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/windows-7-home-premium-laptop-does-not-see-imac/046aea63-d26d-4917-822e-b25f9155baec
but the dword value should be 2, not 1
Next, delete all mappings and credentials related to those mappings. Reboot.
Create a credential with the actual IP address and not the name of the server. Use your regular name and password without the domain prefix.
You’ll notice that the credential now has an enterprise persistence state.
Lastly map the network drive using the IP address instead of the name i.e. \\192.168.0.3\movies
Good luck,
This took me 3 hours to get working!
-Devan
Thanks Gary
Reg edit fix worked great
Much appreciated
Has anyone run across the problem of the Credential Manager losing the drive mapping after the local workstation changes the local user password (not the networked user). I go into the Credential Manager and the Windows credentials is blank.
BACKGROUND:
I have local Win 7 Pro 32bit workstations who login using the local user. These workstations have drive mappings on a Server 2008 32bit Standard edition. The local workstations change their passwords every 90days but the account on the server does not require the passwords to be changed. User names on WS and Server are the same but have different passwords. Every 90days after the local workstation has changed their password I need to enter the credentials again for the server because the entry (which has worked for the last 90days) is missing.
Dale,
I’ve not experienced what you’re describing; sorry.
Thanks very much Gary, this finally worked for me but I had to do a few extra things to get it to work.
I felt it was worth noting how I did it. Follow Gary’s procedure above and after you have completed it disconnect/delete your networked drive mapping then go into the credential manager and delete the credentials for that network resource. Once you have done this remap the network share you removed selecting the “Reconnect at logon” check box, I also checked the “Connect using different credentials” box because we are not using logon passwords on our PCs at home, not sure if this is necessary but it worked, I suspected windows might pass the blank password but again I’m not sure. Check the Credential Manager and look at the saved credentials, it should now say “Enterprise” after persistence and should survive multiple reboots!
Hope this helps someone!
Thanks again Gary!
Hi Lee,
I’m glad that you got it working, and thanks for the extra information that you’ve provided. Hopefully that will be useful to others..
Don’t know if this has been posted here already, I didn’t get through every post.
I didn’t come up with it obviously, but after searching endlessly I finally found a fix that worked for me. Sometimes when searching Google and all the other blogs it really makes a difference what you’re question is.
Anyway I thought on my last search to include HomeGroupUser$ as apart of my issue with the Credential Manager forgetting the settings.
Exact Search: credential manager forgets HomeGroupUser$
And I came across a site that seemed to indicate that the HomeGroup was the issue. Well for me, as it turned out, it was.
To fix it I had to remove / delete all my Windows 7 computers from the Home Group, then build a new one. Once I did that the system stopped reverting back to ‘incorrect’ settings.
One of the things I couldn’t wrap my head around was that even after deleting Credential Manager Credentials, they would invariably be right back to where they were after a reboot. Turns out that with the Home Group all the machines kind of handshake all that information. So by deleting and redoing the Homegroup on all machines, problem solved.
Hope this helps anyone else that all other solutions wouldn’t work for. Thanks.
Forgot one detail… When mapping the drive, it won’t create new Credential Manager settings unless you click the ‘Connect using different credentials’ checkbox.
That depends.
Depending upon the specific version of Wi ndows that you’re running, that box may, or may not, show.
Thanks.
I do not use the homegroup feature. I’ve got so many different computers here, running OSX, as well as various shades of linux and various shades of Windows that I cannot be bothered introducing that into the mix.
I think that, in my situation, that would break many things, and my situation is already complex enough that I don’t need more proprietary networking “features” that in reality add no real functionality into the mix.
After couple of hours I almost got desperated to properly and conveniently connect our new Win7Ultimate to our OSX-Server (with WInXP was no problem so far).
Thank you very much for this tip to a lonesome mostly MacUser desperately working on two OSystems.
one more question
Does anyone know any forum that discusses issues about the “relation” between Win7-Clients and MacosX6(or7)- Server and – Clients?
Both companies (MS and Apple) are very short on support of this.
Thanks
Gary, just wanted to say THANK YOU! You would think that MS would have resolved issues like this already. Anyway, so glad I found this blog. Being a mixed shop (Mac and PC) this problem was absolutely driving me nuts! I now have this setting being applied domain wide.
Again, Thank You for taking the time to share your knowledge.
THANKS! This is the ONE solution that I’ve found to this goofy problem that actually worked.
Thanks a bunch! This fixed network replication for us in a enterprise enviroment 🙂
[…] only Set the Minimum session security for NTLM SSP Disable Require 128-bit encryption Source: Windows 7 – Fixing The Mapped Drive Credentials Problem | The Gadget Grill If that doesn't work try adding the credentials manually. To open the Credential Manager and add […]
What worked for me was to reformat and upgrade to Win 7 Ultimate. That network logon screen never appeared again even on initial access to my NAS! Awesome…
Good work Gary. I’m an IT Pro and this thing is an issue moreso on 64 bit systems I’ve found. Works a treat with NAS mappings as well. Good fix and good explanation – you’re to be congratulated.
I had reached the point of despair over this problem but by chance found your answer. It works brilliantly. Sincere thanks – even forgive you for the cricket!
After much experimentation this didn’t work for me in Windows 8.1.
The workaround was to use a Microsoft Account (as Microsoft funnels you to do) on both (peer-to-peer) computers.
For private folders, on the “Server” (a regular Win 8.1 Pro machine): I set share and NTFS (“Security Tab”) permissions with the Microsoft account. On the “Client” (also a Win 8.1 pro) I’ll automatically get access to these shares (and can map them without having to change credentials).
For public folders: I join the Homegroup in both computers. On the “sever” I use Advanced Sharing and grant “HomeUsers” Full Control. I also using the “Share Wizard” and grant “Homegroup” Read/Write access. From the client I can connect automatically and map the share without changing credentials.
I encountered a different flavor of the persistent mapping problem. For me getting a persistent entry into the credential manager only worked when I used a domain name that was different from the local Computer Name. Apparently in my case the remote system did not make use of the domain part of the userid when authorizing access to the drive, so I could use a fake domain name.
Initially, when mapping the drive, I had marked “Connect using different credentials”, and entered the required userid without domain. The mapping worked, but when checking the entry in Credential Manager, I noticed that Windows had implicitly entered the local Computer Name as domain name, and had set the persistence to Current Session. Following the advice given above, I deleted the entry and unmapped the drive. I checked “Network Security: LAN Manager authentication level setting”, but that was already set to “Send LM & NTLM – user NTLMv2 session security if negotiated”.
After repeated tries, I tried using a fake domain that was different from the local PC name. Again the mapping worked, but this time the Persistence setting was set to “Enterprise”.