Locked profiles on sbs 2003 domain.

I'm looking at an Sbs 2003 domain.  The domain has a mix of xp and windows 7 machines, with roaming profiles enabled.  The users who use primarily xp are unable to log onto their domain profiles, instead given the old "you are logging onto a cached local profile" message.  When they delete an item from their profile, it returns upon logging off and logging back on.  Their profile folders are read only on the server, when I attempt to change this I receive an error stating that a folder named "D@1."something is not accessible.  The something changes, thus far it's been either *.lnk and *.docx.  I've logged onto the profile and run a search for the file, it comes up with a test file placed on the desktop, literally named test.
Any thoughts?
Who is Participating?
Hypercat (Deb)Connect With a Mentor Commented:
I would try creating a complete new profile folder for one user and see if that works.  It sounds as though the security settings on these folders have gotten corrupted in some way.  How many users are affected?

To create the new profile folder the way I would suggest is:

1.  Change the name of the profile folder that exists on the server and create a new folder with the correct name and permissions.
2.  Go to the user's workstation, log on as Administrator. Go to the System properties, Advanced tab, Users section and from there copy their local profile (assuming it still exists) to the server and give their domain account permission to that folder. The permissions thing seems redundant, I know, since you've already set up the permissions manually, but do it as a fail-safe to make sure the permissions are correct.

Then log on as the user and see if the profile works.
Hypercat (Deb)Commented:
Are the folder names actually like "D@1." or is that just something you made up as an example?  That's a really weird folder name. Profile folders would normally be named the same as the user's logon name.  Make sure that the XP users' profile folders do NOT have a ".V2" extension - that extension should exist only on the Windows 7 users' profile folders.

Sounds like the first thing you'll have to do is take ownership of the folder(s).  Then you will be able to change the NTFS security settings so that they are appropriate.  The usual profile security settings would be like this:

Top level shared folder:

Share permissions: Administrators Full, Users (or Domain Users) Change
NTFS permissions: Administrators and System Full, Users (or Domain Users) Modify (This folder only)

Individual profile folders, NTFS permissions: Administrators, System and the individual user should all have Full permission. (Not everyone gives the Administrators group permissions, but I've found that not doing this can cause problems managing these folders when problems arise, as you're experiencing right now.)
wcoilAuthor Commented:
D@1 is the actual name of the file, not folder.  Profile folders do all have proper names.  Some of these individuals do have Profile.v2 folders, some do not.  The problem lies in the non-.v2 folder.  Ntfs Domain Users had no rights.  I modified this, still the same issue.  It's worth noting that the raid array on this server crashed last week and everything on it was rebuilt from backup.
wcoilAuthor Commented:
We just ended up recreating the profiles on the server and that fixed the issue
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.