0

TLDR; I can't figure out where the value for %appdata% is set for RDS servers. This appears to be different from the "Remote Desktop Services User Profile" directory in ADUC, as I can successfully manipulate that value and have it propagate.

I am attempting to moving RDS user profiles from one server to another. I've robocopy'd all of the profiles over to the new share and have shared it, and confirmed it is functional with my regular user account. Even though the fields in ADUC are populated with the new server information, the change does not trickle down.

I've come across a Powershell script that will search all of the GPOs, and when I searched for the old server name I found a policy that was also redirecting AppData (Roaming) in

User Configuration / Policies / Windows Settings / Folder Redirection / AppData (Roaming)

And I changed that to the new server, ran gpupdate /force on my RDS server, and logged in. When I run gpresult /r I see it shows the correct share for the Roaming Profile field. When I echo %appdata% it still shows the old share. I cleared this GPO and updated with no noticeable change.

When I clear the contents of the RDS user profile field in ADUC, gpresult /r still shows me as having the correct Roaming Profile value, but makes me a local profile (which is reflected in echo'ing %appdata%). In gpresult /r the Roaming Profile field is now blank.

When I set the contents of the RDS user profile field in ADUC to the new share, %appdata% shows the old share (likely from the GPO mentioned above) and gpresult /r shows the new share. What is curious is that %appdata% shows \oldserver\tsprofiles$\Application Data rather than AppData like I would expect.

It should be mentioned that this is a fairly old domain (est. 2008), and started out with both Domain and Forest functional levels at 2003. They are currently 2008 R2 (this project is getting rid of the last two 2008 R2 servers in the domain). During this testing I've authenticated to each of the 3 domain controllers currently running (2 are 2008 R2), and have checked DCDIAG and replication status and found no issues.

So at this point I think I have established that the RDS User Profile directory is not being set through ADUC, but the population of that ADUC field matters. It isn't being set through GPO that I can find, so it would stand to reason it is being cached somewhere or something.

Sqrl
  • 11
  • 3
  • I think this has something to do with the settings for AppData(Roaming):that instructs the policy to "Leave the folder in the new location when policy is removed." I can only assume that this is happening because I am not using the original policy (Default AD "User Policy" to make this change, so I am going to attempt to fix this tonight after hours. I'll report back what happens. – Sqrl Dec 29 '20 at 16:16
  • That doesn't seem to have helped, at least not with my user account. I re-added the AppData(Roaming) policy to both of the places that had it before, and I entered the UNC path a little different for both (e.g. \\SERVER for one, \\Server for the other), and it doesn't seem to have taken for my account at least. I logged in on another users account and checked %appdata% and it showed \\Server, so maybe something is going on, but not that I can reliably check. – Sqrl Jan 01 '21 at 17:18
  • I tried following some instructions to clear the GPO cache on my test server, but still no luck. As this point I'm considering just decommissioning the server currently hosting the TS profiles (its a DC) and just switching the dns for that server to the new location. If anyone happens to notice this, please let me know if this is an awful idea. I am really out of ideas on this and cannot afford to blow this when everyone tries to log in next. – Sqrl Jan 01 '21 at 18:05
  • Actually, scratch that last comment. Looking at decommissioning that DC and just making a small Linux server with SMB to host just those TS profiles in an attempt to further segregate duties. Thoughts? – Sqrl Jan 01 '21 at 18:20
  • Haven't been able to make much progress on this, other than the weirdness around the Remote Desktop User Profile field in AD and how it reflects in %AppData%. If I make it literally anything with the original server (e.g. \\oLdSeRvEr\tsPROFILES$) this change accurately reflects in the variable. If I change it to the new server at all, the variable consistently returns the old server and share all in lowercase (e.g. \\oldserver\tsprofiles$) like it has historically been. I've gone back and forth with this several times throughout the last few days and it follows as far as I have seen. Weird! – Sqrl Jan 05 '21 at 16:46
  • I came across an interesting article talking about setting the APPDATA directory in the default profile for the machine. Might give this a shot tonight, placing here for posterity since this has become my blog. https://liquidwarelabs.zendesk.com/hc/en-us/articles/210634163-How-To-Make-APPDATA-and-LOCALAPPDATA-Environment-Variables-Follow-The-Registry-Keys – Sqrl Jan 11 '21 at 11:25
  • Ok, so her is something REALLY INTERESTING! I had to create a new user today, so I just assigned them to \\newserver\tsprofiles$ right off the bat. I got immediately discouraged because echo'ing %appdata% showed the local directory, so I flipped over to pointing her at the old server. Logged back in, same thing! So I again flipped back to new server and logged in and set up her Outlook, and logging out and back into a different host it stuck! SO, somewhere it is cachine that stupid variable %appdata%. Once I can clear that out for everyone I think I'll be in business! – Sqrl Jan 12 '21 at 17:36

0 Answers0