Browse All Articles > Microsoft "Saved Games" Folder - How I Despise Thee
Many of us in IT utilize a combination of roaming profiles and folder redirection to ensure user information carries over from one workstation to another; in my environment, it was to enable virtualization without needing a separate desktop for each user. It's also an effective way to make sure users who give no thought as to the proper place to save a document don't lose data, and to prevent data from being stolen or lost in the event a workstation dies or is stolen.
However, the biggest battle I have fought in maintaining our new "cloud" environment has been the Saved Games folder. I'm unsure which of the Microsoft security gurus decided this folder needed to be even more tightly protected than the .net Framework folder, yet I am constantly having users call me with error messages on the screen to say they can't reach their AppData folder because the Saved Games folder has messed up the permissions inheritance in the user's profile.
When I check the permissions, all is fine - the appropriate accounts have the proper permissions, and the user is listed as the owner of the profile folder. But enforce ownership or inheritance on subcontainers and more often than not the message, "You do not have permission to read the contents of Saved Games. Do you want ... Full Control?", appears. Of course, answering 'yes' accomplishes nothing as not even the server or domain administrator accounts can do anything with this folder without expressly taking ownership of Saved Games or the entire account folder. The only fix at that point is to have an administrator account take ownership and full control - which at the time you do this you'll notice "current owner cannot be displayed" which leads me to believe Microsoft made their "Trusted Installer" account the owner - then set the user back as the owner and reapply all permissions.
I thought I was about done battling this issue (as I have taken other steps I'll go over later) but the need to move all roaming profiles and redirected folders from an old server to a new one led to the issue rearing its ugly head again. Robocopy is a great tool for copying and moving files, but for a novice like me it can lead to some headaches - especially if you have problems such as Saved Games lying in wait in your environment. I initially performed my Robocopy using the COPYALL option (copy:DATSOU) in order to mirror everything - which had the unexpected effect of breaking permissions in the new redirect location thanks to Saved Games breaking inheritance. After more experimenting and troubleshooting, I believe I have created an effective strategy for dealing with this bothersome folder.
Step 1: Don't redirect this folder!
Redirection is very important in a roaming profile strategy to keep logon times tolerable, but as a novice I did not realize the Saved Games folder would create such a headache. In a business environment you shouldn't have much (or any) data stored in that folder, so leave it with the local profile. When setting up your roaming profile policy, exclude this folder from the profile, and make sure to not configure Saved Games when setting up your folder redirection policy.
Step 2: Don't Robocopy this folder (if you made the same mistake I did)!
I used various options to migrate our redirected folders - I have Robocopy scheduled to run every 4 hours to make sure any users who have not yet had the policies to move to the new server applied don't lose data. Due to my original settings which redirected Saved Games there are multiple user folders on our server which contain a copy. Make sure to add the switch
/XD *"Saved Games"
to your Robocopy command to completely avoid the folder if you also had redirected it. You may also want to avoid the /ZB option if you decide you need to copy Saved Games, and instead only use /Z - this way the file copy will fail and if you're logging the job (as you should be) you'll see "access denied" errors in the log which will point you to the locations you need to fix. Lastly, rather than the COPYALL switch, use copy:DATO which will help prevent breaking the inheritable permissions necessary for a redirected folder to work.
Lastly,
Step 3: Delete 'Saved Games' From Your Redirected Folders!
The best option to fix this headache is to remove it from your roaming profile strategy (as described in Step 1) then delete it from the user's redirected account folder. This will prevent future logon issues for the user and issues for you if you have to migrate the files or develop a homebrew backup strategy.
I truly can't understand the thinking behind making this folder so difficult to work with, or setting permissions/ownership in a manner which prevents a user from accessing their own files over a network. This goes hand in hand with Microsoft's hideous implementation of UAC in Vista which caused so many headaches and a true disdain for the OS, and is in my opinion another example of "jumping the shark" on security where MS seems to be protecting the computer from the user - and thereby making it unusable.
However, the biggest battle I have fought in maintaining our new "cloud" environment has been the Saved Games folder. I'm unsure which of the Microsoft security gurus decided this folder needed to be even more tightly protected than the .net Framework folder, yet I am constantly having users call me with error messages on the screen to say they can't reach their AppData folder because the Saved Games folder has messed up the permissions inheritance in the user's profile.
When I check the permissions, all is fine - the appropriate accounts have the proper permissions, and the user is listed as the owner of the profile folder. But enforce ownership or inheritance on subcontainers and more often than not the message, "You do not have permission to read the contents of Saved Games. Do you want ... Full Control?", appears. Of course, answering 'yes' accomplishes nothing as not even the server or domain administrator accounts can do anything with this folder without expressly taking ownership of Saved Games or the entire account folder. The only fix at that point is to have an administrator account take ownership and full control - which at the time you do this you'll notice "current owner cannot be displayed" which leads me to believe Microsoft made their "Trusted Installer" account the owner - then set the user back as the owner and reapply all permissions.
I thought I was about done battling this issue (as I have taken other steps I'll go over later) but the need to move all roaming profiles and redirected folders from an old server to a new one led to the issue rearing its ugly head again. Robocopy is a great tool for copying and moving files, but for a novice like me it can lead to some headaches - especially if you have problems such as Saved Games lying in wait in your environment. I initially performed my Robocopy using the COPYALL option (copy:DATSOU) in order to mirror everything - which had the unexpected effect of breaking permissions in the new redirect location thanks to Saved Games breaking inheritance. After more experimenting and troubleshooting, I believe I have created an effective strategy for dealing with this bothersome folder.
Step 1: Don't redirect this folder!
Redirection is very important in a roaming profile strategy to keep logon times tolerable, but as a novice I did not realize the Saved Games folder would create such a headache. In a business environment you shouldn't have much (or any) data stored in that folder, so leave it with the local profile. When setting up your roaming profile policy, exclude this folder from the profile, and make sure to not configure Saved Games when setting up your folder redirection policy.
Step 2: Don't Robocopy this folder (if you made the same mistake I did)!
I used various options to migrate our redirected folders - I have Robocopy scheduled to run every 4 hours to make sure any users who have not yet had the policies to move to the new server applied don't lose data. Due to my original settings which redirected Saved Games there are multiple user folders on our server which contain a copy. Make sure to add the switch
/XD *"Saved Games"
to your Robocopy command to completely avoid the folder if you also had redirected it. You may also want to avoid the /ZB option if you decide you need to copy Saved Games, and instead only use /Z - this way the file copy will fail and if you're logging the job (as you should be) you'll see "access denied" errors in the log which will point you to the locations you need to fix. Lastly, rather than the COPYALL switch, use copy:DATO which will help prevent breaking the inheritable permissions necessary for a redirected folder to work.
Lastly,
Step 3: Delete 'Saved Games' From Your Redirected Folders!
The best option to fix this headache is to remove it from your roaming profile strategy (as described in Step 1) then delete it from the user's redirected account folder. This will prevent future logon issues for the user and issues for you if you have to migrate the files or develop a homebrew backup strategy.
I truly can't understand the thinking behind making this folder so difficult to work with, or setting permissions/ownership in a manner which prevents a user from accessing their own files over a network. This goes hand in hand with Microsoft's hideous implementation of UAC in Vista which caused so many headaches and a true disdain for the OS, and is in my opinion another example of "jumping the shark" on security where MS seems to be protecting the computer from the user - and thereby making it unusable.
Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.
Comments (0)