Office 2013 opening legacy file formats as Read Only or Corrupted on RDS? Here’s your fix.
Consider the following brainbuster of a scenario which we recently spent half a day trying to diagnose…. and finally squashed:
You have a Windows Server 2012 R2 RDS (Remote Desktop Services) server that is providing session-based desktops for users at your office. You may or may not be using User Profile Disks with RDS 2012 R2 (we happen to be doing so with this particular client). The server is loaded with Office 2013 in any of its flavors (we are using Office 2013 Standard on this customer server). All of a sudden, one or multiple users are unable to open legacy Office documents in the sub 2007 file formats (.doc, .xls, etc).
They may receive one or more of the following style of errors denoting that files are corrupt or that files are in use and cannot be used in Read Only mode (we saw a scattering of each when this happened, hitting both .doc and .xls legacy Office files). This did NOT affect newer Office 2007+ files in the new XLSX and DOCX formats however:
After plugging and chugging for nearly half a day on this, trying all kinds of things from DDE changes, to Trust Center adjustments in Excel/Word, to a few other fixes which did not help.
So what did it? After a long and hard peruse of Google, we found the following post from none other than the official Excel Support Team titled “File locked for editing by ‘another user’ opening or saving file in Terminal Services environment“. This was just the information we were looking for. And it was related specifically to a terminal services (or Remote Desktop) style environment, which is what we were having the problems within.
To make a long story short, the article from Microsoft’s Excel team is a bit long and convoluted but discusses the issue at hand: Office is trying to save items to a per-session temporary location which can very well change between each time a user logs into their remote desktop. I’ve never encountered this being a problem, but it seems that RDS is setup (via Group Policy of the RDS server instance, by default) to use an odd and relatively unknown option called temporary folders per-session.
While I don’t care very much what is going on behind the scenes, as it seems like a rather improper way to use temporary folders, but Windows treats each RDS session with a different set of temporary folders. And unbeknownst to me previously, Office relies on these temporary locations to save autorecovery and other sensitive office file data in RDS sessions. For users who experience this issue, it could be that their specific per-session temp folders either are not being created properly, or are changing between sessions and throwing off the way Office works.
Why this only affects pre-2007 file formats is beyond me. All I know is that we had this nasty bug, and the following edits to the local group policy of the RDS server (a Hyper-V instance, in our setting) resolve this fairly quickly.
Microsoft led me to the proper GP location by their article, but it was formatted with references to what seems to be 2008R2 era policies – ones that have changed considerably since 2012 was introduced.
Regardless, here is the location to find this little bugger in Server 2012 R2 (same for 2012 I presume):
- Open gpedit.msc from RUN command as a domain or local server admin (of the RDS server – NOT any other server!)
- Drill down to: Computer Configuration –> Administrative Templates –> Windows Components –> Remote Desktop Services –> Remote Desktop Session Host –> Temporary Folders
- Find the policy called: Do not use temporary folders per session
- Change this option to Enabled
Like magic, upon next fresh login for the affected user, the problem was gone. Office was opening faster than ever before, and old legacy Office files were opening without issue of any sort.
Here is the Group Policy item in question that was causing us massive headache (yellow denotes the changed option, post fix):
And that was it. Save yourself hours of frustration and give this a try. If you have multiple RDS servers in a cluster or pool, you would probably want to implement this GP edit on a domain scale. Since we only have one RDS server for this client, I applied this on the local GPO level of the machine itself. Either way, it should fix your headaches.
Good luck!
Credit for Header Image: File Extensions
