[SOLVED] Connecting to shared folder using MS account

[glricht]

I have a small customer using a Win 7 Pro PC as a small file server in a Workgroup (not AD) environment. All userids/passwords on the workstation PCs are defined in the file server and the access permissions on each folder on the server are setup appropriately -- e.g. Sally can update Folder-A, but not Folder-B, Bill has read-only to Folder-B, John has full control over both folders, etc. The client PCs are a mixture of Win 7, Win 8.1 (local account) and even an XP machine (yeah, I know ... sigh). This has been working just fine for about a year.

About two months ago, one of the Win 7 Home Prem users upgraded to Win 10 Home using a local account (same userid & password as before) and Win 10 connected to the network share on the file server as expected.

But last weekend, that same Win 10 user switched from a local account to a MS Account and can no longer access any of the network shares (he gets the "resource not available" generic error message).

For example: the user's old local account userid was "Amy Jones" with a password of "MyPassword". The MS Account email addr is "amysallyjones1234@outlook.com" and uses the same password.

When the user logged on using the MS Account and the access failed, I figured I just needed to define to the file server a new user, but wasn't sure what userid to use. I tried "amysallyjones1234@outlook.com", but Win 7 wouldn't even allow a userid of that length. I've tried "amysallyjones1234", looked in C:\Users and tried that name, but still no access. Was going to try the local account again, but the user had already deleted it and I ran out of time at the customer's and didn't get a chance to define it again and try it.

I'm back in the office and have Googled this for quite a while and found others having similar problems, but no real answer.

Has anybody run into this in a workgroup environment? I've used this technique for years and it's worked very well, but this is the first time I've had a client PC using a MS Account as opposed to a Local Account. I hope the end result is not that only Local Accounts can be used.

 

[nlinecomputers]

Connect to your share with an alternate login.

http://superuser.com/questions/727944/accessing-a-windows-share-with-a-different-username

 

[nlinecomputers]

You could also just setup HomeGroup and share access via that.

 

[glricht]

Connect to your share with an alternate login.
http://superuser.com/questions/727944/accessing-a-windows-share-with-a-different-username

Thanks for the link, I hadn't found that one.

Sounds like it might work, but it's for mapping a drive and I wanted to stay away from drive mapping. Today, the customer has a shortcut link on his desktop that uses UNC (e.g. \\servername\foldername) to open the shared access folder. There are about 5-6 shared folders and having to dedicate a drive letter for each might be unwieldy. But gives me something to ponder.

 

[trevm999]

At least in previous versions of Windows, you can put the credentials into credential manager and then it will use them when accessing those shares. If you select the box to "remember my credentials" when it gives you the "enter network credentials box" it will do it for you automatically. No need to map drives

 

[nlinecomputers]

At least in previous versions of Windows, you can put the credentials into credential manager and then it will use them when accessing those shares. If you select the box to "remember my credentials" when it gives you the "enter network credentials box" it will do it for you automatically. No need to map drives

Yep. Windows 10 still does this. He may have to remove the old creds and reset it up. But the first time he tries to connect he should get a prompt. Nothing has changed here.

 

[nlinecomputers]

I'll even go further and say that changing to a M$ account should NOT have affected mapping. The Microsoft account is LINKED to your old login it doesn't fully replace it.

 

[glricht]

Last weekend, I recreated the customer environment in my shop and determined how to make things work the way I wanted. As others have suggested, using the Credential Manager is what made the difference. (Please refer to the OP to understand the environment.)

Testing and observation revealed the following behavior:

1. If the client workstation uses a local account (e.g. Win 7 or Win 8/10 with a local account) and NO Windows Credential was defined in the Credential Manager, then the user's accountID/password was used to request access to the shared resource on the workgroup file server.
2. If the client workstation uses a local account (e.g. Win 7 or Win 8/10 with a local account) and a Windows Credential was defined in the Credential Manager, then the value in the Credential Manager was used to request access. A side-effect of this technique is that the user can change his workstation's password and still access the network resource.
3. If the client workstation uses a MS Account (e.g. Win 8/10), the only sure-fire way way to ensure the desired credentials are used is to define them via the Credential Manager. Changing the workstation's account from MS to local and back should have made no difference, but testing revealed that: if Windows was initially installed using a MS Account, an account id of the first 5 characters was used; but once changed to a local or to another MS Account I was unable to access the network resource (I was unable to determine the internal id being used nor was I prompted to re-specify the id/password).

Hope this makes sense and helps somebody else down the road.