Let’s suppose you’re the Network Administrator that provides IT support for a company called Globex Corporation based here in Waukesha, WI. You have 100+ users accessing Microsoft Outlook 2013 from a Remote Desktop Service farm (RDS). Unfortunately, without the default file location configured for Outlook 2013, one of the most common helpdesk tickets you receive from end-users is, “I can’t find where I saved my Outlook attachment!”, or “I’m having trouble attaching an Excel spreadsheet to my email in Outlook!”
Despite how much training your end-users have gone through, they are still having difficulty understanding that in an RDS specific environment, the default file location dialog box that appears when they are adding or saving attachments in Microsoft Outlook is –not- actually their local C: drive, but instead, its the RDS host server’s local C: drive. To combat this particular issue, and to minimize the number of helpdesk tickets generated from users, you decide it would be best to configure the default file location when adding and saving attachments. You also decide, you want the default file location to point to the user’s home folder/drive (in this example, we will refer to it as a Z: drive).
Sounds simple enough, right? But after spending more time investigating how to achieve this, and some failed attempts at implementing this, you started to wonder… Why did Microsoft have to make this so difficult? In some cases, using Folder Redirection might work as an alternative, but you decide to stay away from that for a variety of issues.
It seems like setting the default file location for attachments in Microsoft Outlook –should- be a simple thing, not only to implement, but to automate as well. But, unfortunately, it can be rather confusing because Microsoft, in their own infinite wisdom, decided to make the default file locations –DIFFERENT- depending on whether you’re a) adding an attachment to your email message, or b) saving an attachment from an email message.
This Wisconsin manufacturer needed to modernize its IT infrastructure to support rapid business growth.
Discover what they didAs a result, the configuration settings needed to specify the default file location for adding an attachment In Outlook 2013 is completely different from the configuration settings needed to specify the default file location for saving an attachment in Outlook 2013.
Since we are going to tackle these configuration changes via group policy, they obviously need to be configured in different places. Why Microsoft made this so difficult is anyone’s best guest.
Using Group Policy to configure the default file location for adding attachments
The first step in configuring this setting is downloading the Microsoft Outlook 2013 ADMX files and policy definitions for group policy. You can find those here: https://www.microsoft.com/en-us/download/details.aspx?id=35554
Once downloaded, make sure you place the appropriate ADMX files in your
\\Server\SYSVOL\DomainName\Policies\PolicyDefinitions folder, and the ADML files in your \\Server\SYSVOL\DomainName\Policies\PolicyDefinitions\en-us folder.
Now we can edit the GPO we normally apply to our RDS host servers. (Keep in mind, most often, RDS host servers will have GPO’s that have Loopback Processing mode Enabled (with either the Replace or Merge option enabled) so user-based settings are applied to the RDS host servers themselves.)
So let’s edit the GPO that we apply to our RDS host server. We want to navigate to this particular section which is located under User Configuration -> Policies -> Administrative Templates -> Microsoft Word 2013 -> Word Options -> Advanced -> File Locations.
Now, you might be wondering…. Why am I making this configuration change in Microsoft Word 2013 and not the Microsoft Outlook 2013? GOOD QUESTION! Once again, Microsoft leaves us scratching our heads on this one. This is actually where you adjust the default file location for adding attachments in Outlook 2013. You won’t find ANY option to edit this within the Microsoft Outlook 2013 ADMX template — Nope, that would just make too much sense! (If I had to guess, I suppose it’s located under the Microsoft Word 2013 ADMX template because Outlook 2013 uses Word 2013 as it’s default mail editor?! Who knows…)
Anyways, make your change as follows:
Now, the default file location when ADDING attachments will be the user’s home folder/drive (Z:) – instead of the RDS server’s local C: drive.
Using Group Policy to configure the default file location for saving attachments
The next step is slightly more difficult because Microsoft did NOT provide a setting in their Microsoft Outlook 2013 ADMX files and policy definitions, for changing the default file locations when it comes to actually SAVING attachments in email. Why? Another good question.
But we can work around this oversight but creating our own ADMX/ADML files for this functionality. The easiest way to do so is to use this amazing script: http://mscosentino-en.blogspot.com/2010/02/convert-registry-file-to-admx-policy.html written by Mariano Cosentino.
But first, open Notepad and copy the following into it:
-Begin copying below this line-
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Outlook\Options]
“DefaultPath”=”Z:\\”
-End copying above this line-
Save the Notepad file in your c:\temp directory as: Outlook-Save-As.reg
(Please note, the path in the registry file is defaulted to the user’s home folder, which is their Z: drive.)
Now, refer to the instructions in the link above and run the command CSCRIPT.EXE REG_2_ADMXL.vbs c:\temp\Outlook-Save-As.reg en-us. It will generate an ADMX and AMDL file you then copy to your \\Server\SYSVOL\DomainName\Policies\PolicyDefinitions and \\Server\SYSVOL\DomainName\Policies\PolicyDefinitions\en-us folders accordingly.
Now, edit the same GPO that applies to your RDS host servers and set your DefaultPath option to Z:\ (if it’s not already configured for you).
At this point, your users will finally have their default file location set to their Z: drive for BOTH adding attachments to an email, and saving attachments in an email. Maybe Microsoft will eventually make this a bit easier. At least we can hope!