[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 483
  • Last Modified:

Mapped Drive wont reconnect

We have a workgroup; 2 WinXP machines and 2 Win7 machines, both are "home" version I believe. I just added a box to act as my "file server". Its a WinServer2008R2. I left the workgroup setup per client request to avoid dealing with domain management. All we want to do is create a share on the server, drop all files from the 4 computers into the server, and have a mapped drive from each machine to the server to access the files. Simple.

On the server, I created a folder and shared it to "Everyone" group with Read/Write access. There is no file security per intent. This is just a open sahre machine, later to be converted to a full AD Domain. for now, its just a file repository with backup.

On client each machine I disconnected all mapped drives and even removed the mountpoints in the registry. I created mapped shares using /savecred and /persistent:y but everytime the user logs off and back on again, the workstation requires a password to be entered before the drive will connect. This behavior is the same on both Win7 adn the WinXP boxes.

Any direction will be greatly appreciated. Why wont the mapepd drives remain after log off/ log in?
0
ramitchell0954
Asked:
ramitchell0954
  • 4
  • 2
  • 2
  • +2
2 Solutions
 
mcsweenSr. Network AdministratorCommented:
Control Panel, User Accounts, Manage your Credentials or Manage your Network Credentials (Win 7 or XP) then add the credentials for the server there using the an account that exists on the server.  If you don't care about security you can just create one account to use at all the clients.

Your other option is to allow anonymous access to the server which I strongly advise against, but this can be done from local security policy on the server (start, run, secpol.msc)

Local Policies, Security Options,
"Network Access: Let Everyone permissions apply to anonymous users"
"Network Access: Restrict anonymous access to Named Pipes and Shares"
"Network Access: Shares that can be accessed anonymously"

Also make sure you check the Share and NTFS permissions on the shared folder at the server.
0
 
K_WilkeCommented:
I always work with Pro editions of XP and 7 since home editions have problems with AD and Windows 2008.
I am just asking, could this be the problem?  Knowing that home editions cannot get onto an AD domain, if a Windows 2008 server has a share, could home edition only do the share for a while then will not be able to do the share?
Thanks,
Kelly W.
0
 
warddhoogheCommented:
You may not have stored the password, the following example might help you:
net use Z: \\SERVER\SHARE password /savecred /user:SERVERNAME\useraccount /PERSISTENT

Note that in a non-domain aka workgroup situation like yours currently, you always have to specify a user account which exists on the target 'server'.

PS: 'home edition' (XP/Vista/7) cannot be joined into a domain.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
joeyfazCommented:
If you match the credentials on the server and the workstations, then it all becomes a no brainer and then there will be no need for any security compromising like using everyone or anonymous accounts.
0
 
ramitchell0954Author Commented:
I am aware that "home" editions are not domain attachable. This is the primary reason no domain configuration was established, and it was left was a workgroup. In a year or so, all clients will be upgraded and at that time a full AD domain will be created. Until then - workgroup only.

None of the shared files can reside on the clients. This defeats the purpose of the new file server. Local client file storage will be maintained for confidential files only, with no network access to the local clients.

Individual workstations must have unique user logins. Each user has outlook files as examples, and other confidential files, that only that user can access. Not much of a security policy, but for them it works for now.

Anonymous access may be whats needed here - I'll give that a try.

joeyfaz: explain please what you mean about matching the credentials on the werver and client. Are you saying have all the users log into their workstations using the login/password for the server? if so then everyone would be able to access any workstation and the simple securty model we have doesnt exist anymore. If thats not waht you mean, can you explain?
0
 
mcsweenSr. Network AdministratorCommented:
What you have to do is create the same user on the server as the user on the client; both of these accounts must have the same password.  If they change it on the client then it will have to be changed on the server.
0
 
ramitchell0954Author Commented:
Thank you all for replying. I actually solved this problem by creating a .bat file and placing it in the startup folder for each user on the client machine. I used "net use" to map the drive on each logon.

I did agree with mcsween that anon access is a bad idea, but at the time, I didn't realize that in a non-domain workgroup peer network like we have that creating a user on the server that matches the user on the client woudl allow resource access. I guess I could have tried that, but the batch file worked well. mcsween and joeyfaz thank you for your input.I'll try that next time I'm at the client site.

warddhoogie: the /savecred in your command throws an error. /savecred will prompt for username and password. You cant use both /savecred and /user in the same command line. I didnt try your command line since I already know those switches do not play nice together. thanks but that didnt work.

I answered K Wilke in the past post.

The solution that I came up with was distinctly dissimilar to any of the suggested solutions. I am therefore requesting the points be credited back to myself. If you disagree, please let me know why and an explanation as to why your solution matches the startup batch solution I created.

0
 
ramitchell0954Author Commented:
I've requested that this question be closed as follows:

Accepted answer: 0 points for ramitchell0954's comment http:/Q_27300865.html#36531340
Assisted answer: 0 points for ramitchell0954's comment http:/Q_27300865.html#36515309

for the following reason:

Since no rebuttal was made to awarding the points to myself, I have closed this issue.<br /><br />thank you all for helping!
0
 
warddhoogheCommented:
distinctly dissimilar?  I offered a NET USE example with parameters useful for fixing your problem (off the top of my head, sorry for not testing)
since you clearly used that suggestion, amending an example to your needs, i'd appreciate a few points.
0
 
ramitchell0954Author Commented:
I'll agree and split it with you. It was in fact your comment that prompted me to think of running batch files afterall...

thank you again!
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

  • 4
  • 2
  • 2
  • +2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now