• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 436
  • Last Modified:

Non-domain workstations saving files on domain server

I have a small client with one server, recently upgraded from SBS2003 to SBS2011, and 5 Windows 7 workstations.  For reasons unknown to me, the previous IT guy setup all of the workstations on a workgroup rather than the domain.  They also set all of the local and domain usernames/passwords the same to make connecting to network resources easy.

We're having an issue where after a user opens a document off the server, makes changes, and then saves the document, nobody can access the document until I reset the permissions, not even the last user to save it. If I login as a domain admin I can't even view the permissions or owner of the file, the owner says Unknown User, and I just have to take ownership and reset the file to inherit permissions.

I've never seen this happen, and it was not a problem on the old server, but I'm guessing it has to do with the non-domain computers not acknowledging the existing domain based permissions. If that makes sense?  My inclination is to switch all of the workstations over to the domain, but I hate the whole user profile migration process and the downtime involved for each user.  At least it's only 5 users though.

Has anyone else seen this issue?  Do you have any suggestions for resolving it?  Is it something specific to non-domain computers and server 2008/2011?

Thanks.
0
theitdept-support
Asked:
theitdept-support
  • 3
  • 2
1 Solution
 
smckeown777Commented:
First off I'd have to say simplest way to fix this is join the pc's to the domain - pointless having a server running AD where you are not even using the functionality of the domain...

But apart from that, you mention that the local users were all matching on the pc's and the old server - has this same account been created on the new SBS box?

The 'unknown user' simply means it doesn't recognise the username in question, which could mean the username doesn't match a similar user on the server...
0
 
theitdept-supportAuthor Commented:
Thank you for your input. I totally agree on your first point and have encouraged the client to go that direction. They however are pressing the issue that it worked before the migration to SBS2011 and that it was a problem with the migration which we did.

Every user does have an account on the domain. However, now that you mention it, I have not verified all of the accounts on the local workstations match. It is possible somebody is providing their domain password when connecting or told Windows to remember it.

But shouldn't the server being saving those files as the domain user and not the local user?  That's what is confusing to me. I didn't think the server would even be aware of the local user account.

Also, the only domain groups with access to the files are Administrators and Domain Users, the Everyone group is not on the list.
0
 
Larry Struckmeyer MVPCommented:
When a non domain system or user attempts to access a domain system the user will be challenged for domain creds.  Full stop.  So there must be users and passwords on the domain known to, but not necessarily the same as the non domain users.  Not tested by me, but unlike workgroups, where all the users can connect to all the stations if the user names and passwords are the same on every station, a non domain user has to furnish creds to connect as local\joe is not the same as domain\joe.

You should be able to map a drive to the share and make ipersistentnt if you give domain user creds when making the connection and add /persistent:yes to the end of the net use command.

But all of of thisridiculouslous.  Those stations should be domain joined and the users and the stations should be managed by the domain and its group policies.
0
New feature and membership benefit!

New feature! Upgrade and increase expert visibility of your issues with Priority Questions.

 
smckeown777Commented:
The way I understand WORKGROUP perms work is like so

Local user account on pc creates file on the server share - that means the file is created using the PCNAME\LOCALUSERNAME - this is the account which the server will see as Unknown

The server isn't responsible for the creation of files - the user on the local machine is - thus the perms issues...

Note I'm not that hot on workgroup stuff as its been years since I've had to play with them...

The other way to possibly fix this is to add the EVERYONE group to the share/NTFS perms and thus the non-domain users(i.e. the workgroup users) will then have the perms they need...

The way I would approach this is simple - tell the client that you aren't dealing with a 2003 server anymore - this is 2011 and that's how 2011 works, and therefore to get it working correctly you need to join the domain and use the domain accounts to fix...remember you are the expert in this situation not the client(and lets be honest the original setup was NOT the way it should have been done)

Its like everything in IT - things change with newer OS'es, Windows 7 isn't the same as XP...etc, so the correct way to fix this is a domain setup properly...
0
 
theitdept-supportAuthor Commented:
Thank you everyone for the feedback.  Ultimately, for as long as I've been doing this, I guess I need to learn to be more assertive. smckeown777 is right, I am the expert in this situation and I need to present myself as such.
0
 
smckeown777Commented:
Exactly...so many admins these days are being told what to do by 'others' in the business, sometimes I wonder why we bother...these days I handle clients that tell me how to do things by walking away...not worth the hassle/bother that it will lead to when things go wrong/break/etc...

So good on ye!! Good luck with the job either way...
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

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