Roaming Profile Folder Creation Immediately Inaccessible

Question

Set up is AD 2008.  Terminal 2012 R2, Fileserver 2012.
Before we've had it set so we could create a user in AD, log them onto the Terminal, it creates the profile, which on log out is saved to its roaming location on the Fileserver with a V2 after it.  In their profile field in AD, that Fileserver location
was given as well.
Something changed recently and we're not sure what.  Now if I create a user in AD, and log them into the Terminal, it gives me a message that a temporary profile is being used for this log on.  When I log out, it creates the V2 on the Fileserver,
but I'm unable to access it even with admin credentials.  I've been able to change the owner, but it doesn't allow me to delete that folder and try again.  I have been able to run this
SET DIRECTORY_NAME="C:\profilelocation"
TAKEOWN /f %DIRECTORY_NAME% /r /d y
ICACLS %DIRECTORY_NAME% /grant administrators:F /t
PAUSE
where the profile location is the folder in question and have it open it up enough to delete so we can troubleshoot.  But doing that doesn't change the initial Terminal status of using a roaming profile and it using a temporary profile.
On the terminal server, I have also found the registry setting for that user and deleted it (the one with the .bak ending).  That allows a good logon if I remove the profile location setting in AD.  But when I move the folder to the fileserver,
and then add the location back in AD, I get the Temporary Profile error again.
Any ideas where to start looking?  I don't think we've changed any GPs that affect our terminal users.  Current users are fine, but I won't be able to create any new users and have them use a roaming profile.
Ben Rollman

Answer 1

Well, I'm still not sure what changed.  Here's what I've done so far.  (Email to my boss yesterday.)
I set up a test container under States and moved all the state user, test user, etc into it.  Then I backed up the current ExtUsers_UsersGPO settings and imported them
into a new GPO called TextExt… and enabled the computer settings.  It had the following but the Computer Setting wasn’t enabled so it wouldn’t have done that.
Policy
Setting
Comment
Add the Administrators security group to roaming user profiles
Enabled
I deleted the local and roaming file, and for good measure the registry entry.  I logged in as “testuser” and didn’t receive any problems.  Created a test folder,
test file, logged off.  I see the testuser.V2 on the FS, but I can’t access it, like before.
I run the following script to change it so I can access it.
SET DIRECTORY_NAME="C:\Files\Profiles\testuser.v2"
TAKEOWN /f %DIRECTORY_NAME% /r /d y
ICACLS %DIRECTORY_NAME% /grant administrators:F /t
PAUSE
The FS profile is set for full rights for domain and local admin, but no user.  So I add the user as the owner, and give the user full rights.  Log in, and I get
this.
Your roaming profile is not synchronized correctly with the server. Windows will load your previously-saved local profile instead. See the previous events for details.
And these in event viewer.
Windows cannot copy file
\\statefs\Profiles\testuser.V2\ntuser.ini to location C:\Users\testuser\ntuser.ini. This error may be caused by network problems or insufficient security rights.
DETAIL - The system cannot find the file specified.
Windows could not load your roaming profile and is attempting to log you on with your local profile. Changes to the profile will not be copied to the server when you log off. Windows could
not load your profile because a server copy of the profile folder already exists that does not have the correct security. Either the current user or the Administrators group must be the owner of the folder.
I had put the icons on the FS folder just to see if it would show up.  I saw the test folder okay in both.  But when I logged back in, the shortcut icons weren’t
there.  AND when I logged off, it overwrote the FS folder, removing the icons.
From there I checked the TS local profile folder (just in case) and saw it had no testuser rights at all.  The owner of that folder was SYSTEM.  So just for fun I
changed the owner to testuser, made sure to set it for all subfolders, logged in, no error message.  Logged out, put shortcuts into the desktop folder on FS, logged back in, no errors and the shortcuts are there.
So.
I don’t know if it’s the GP or the fact that maybe the TS folder wasn’t getting the right permission to allow the roaming process to write to it or both.  I’m going to
try to recreate this, see if there’s a way to shorten the process or create a template like before.
Ben Rollman