How to deal with the extremely big *.ost files in a Terminal Server environment which is running out of space

Question

Our Terminal Server is running out of hard disk space, and the major files which occupy most of the space are *.ost files of the Outook, which come form the users which use the Terminal Server all the time through remote desktop. The Outlook is installed on the Terminal Server and various users can use it.

What would be a solution in this case. Is there a way to limit the size of the *.ost files? I read in forums that having the Outlook 2010 set up in Cached Exchange Mode isn't the best practice for an environment where the hdd space is a major constraint.

First thing that came to my mind is using folder redirection, and place the ost files (together with the AppData forlder) in a network share, but this does not help, because the ost files are saved a part of the AppData folder which can not be redirected.

Then I thought if it is possible to limit the size of the ost file? Or limit the time that it keeps emailed cached, say just emails from the last 6 months are sufficient.

Another solutions that came to my mind, moving the ost files somewhere else, this required the old ost file to be removed, and creation of a new one. I am not quite sure if the new OST file will still have cached the emails which where available in the old ost, or will it start caching from where the other one left.

What do you suggest?

Solution 1

1. If you can avoid it, don't use cached mode on a Terminal Server. It's almost pointless to do so. One of the reasons to use cached mode is so that the client can use Outlook while disconnected from the network or from the Exchange server. The former would never happen, otherwise the user wouldn't be able to log on to the TS and therefore couldn't use Outlook in offline mode, and the latter almost never happens, unless the Exchange server is offsite.

2. You can set the default path for new OST file using Group Policy. You'll need the appropriate Office version ADM/ADMX files in order to do so. Note that this will affect new OST files, not existing OST files, so you'll need to remove the existing OST files by toggling cached mode off and on, deleting the existing OST file in between.

3. An OST file is a cached copy of the mailbox. Creating a new OST file doesn't "pick up where the last one left off". A new OST file should contain everything the old OST file contains. If an item is in the mailbox then it should be in the OST file. An OST file does not contain items that are not in the mailbox, so the user will not "lose" items by deleting the old OST file.

Solution 2

Don't use cached mode...if you want to limit the size, Outlook 2013 can do that (slider on the account settings) easily. Not using cached mode with a local Exchange server isn't that big of a deal, as long as your Exchange server is always online. It's not ideal, but it's doable and won't cause any heartache for the users.

Or you can have them use OWA instead of Outlook.

And yeah, you can limit the size of the OST file, see here: http://support.microsoft.com/kb/832925 - but I've only seen this done in one shop I know of, and the results were mixed (some clients got errors when bumping against the limits using Outlook 2010).

Solution 3

We enabled cached mode on Terminal Servers because it was the only way to get Instant Search to work in Outlook 2013 connected to Exchange 2013.

Solution 4

You might consider a brutal hardware hack and just upgrade the servers disk space. As soon as you are hitting a limit with any program, you will soon run into problem with others too.

View more solutions

Comments

[Nathan C]

Storing .ost files over the network is a bad idea anyway since Outlook doesn't like network drives (especially with .ost files). If you remove the OST file, Outlook automatically syncs with Exchange again to download the files. Why do you even have Outlook on a terminal server anyway?

[Kristof Tak]

@NathanC honestly I don't know why we have it there; When I came that was the setup that I found. I believe it has to do with the fact that we don't want to install the office suite to each device when someone new joins the company. Basically, everyone that works in the office connects to the Terminal Server throught remote desktop and they work on the Terminal Server. That's why their ost files are there, and not in their local machine. What is your take on that? Good design, bad, suggestion?

[Kristof Tak]

@TheCleaner what would be the consequences of not using the cached mode?

[joeqwerty]

There's nothing wrong with having Outlook on a TS/RDS server. If you "deliver" your applications to your users via TS/RDS and if Outlook is one of those applications then what's the problem? Microsoft Office is a perfectly acceptable suite of applications to "deliver" via TS/RDS. I've been managing a TS/RDS farm for 10 years and the primary application our users use is Outlook.

[joeqwerty]

what would be the consequences of not using the cached mode? - The only consequence is if the Exchange server is unavailable then users wouldn't be able to use Outlook.

[Kristof Tak]

Outlook 2010 does not provide the "slider on the account settings" option?

[kralyk]

@WolfgangKuehne - I don't believe so...office.microsoft.com/en-us/outlook-help/… - I don't have any 2010 clients around anymore, but I'm pretty sure it was introduced in 2013.

[blaughw]

Outlook 2010 does NOT have the 'slider' to configure cached data.