<div>
<i>What am I doing wrong? &nbsp; How are they coming back? &nbsp;</i> &nbsp;&lt;-- these files should not be on a network share. Microsoft does not support this. In the case of OST files, Outlook will make them local. That is the correct location.
</div>


<div>
Yep, while it is sort kinda possible to access .PST and .OST files over a LAN, this is not supported, and tends to cause problem. The way that Outlook accesses the data is very &quot;chatty&quot;, an inordinately large amount of traffic will be generated, and corrupt files are almost guaranteed.
</div>


<div>
Incorrect.<br />
<br />
Let me explain the network setup here: &nbsp; &nbsp;RDS Gateway server, 2 RDS session hosts. &nbsp; These are Microsoft features and roles.<br />
<br />
If the OST is stored locally on the C: of the two session hosts then they will have 2 separate OST files. &nbsp; This cannot be the case.
</div>


<div>
<i>the two session hosts then they will have 2 separate OST files.</i> &nbsp;&lt;-- What does that mean? &nbsp;Two Outlook Profiles? &nbsp;Then of course the OST files will be different.
</div>


<div>
I think the official, supported solution here would be to have roaming profiles. That way, the users will see the same desktop, regardless of which terminal server the broker sends them to. Roaming profiles have their own issues, so proceed with caution. <br />
<br />
Personally, I tend to just set users up on terminal servers manually, without using the broker. <br />
<br />
More here:<br />
<br />
<a href="https://technet.microsoft.com/en-us/library/cc742820.aspx" rel="ugc">https://technet.microsoft.com/en-us/library/cc742820.aspx</a>
</div>


<div>
If the computers are workstations and not travelling laptops, turn caching OFF and do not use OST files. They are not needed in workstations.
</div>


<div>
I'll break it down further.<br />
<br />
-User Dave logs in to remote services. &nbsp; Hits the RDS Gateway. &nbsp; Gateway sends him to RDS01.<br />
-RDS01 gives him an OST file in c:\users\dave\appdata.<br />
-Dave logs out<br />
<br />
-User Dave logs in again to remote services. &nbsp;Hits the RDS Gateway. &nbsp;Gateway sends him to RDS02.<br />
-RDS02 gives him an OST file in c:\users\dave\appdata.<br />
-Dave logs out<br />
<br />
Do you see now? &nbsp; He now has TWO OST files. &nbsp; \\RDS01\c$\users\dave and \\RDS02\c$\users\dave<br />
<br />
This is unacceptable and causes a wide range of issues. &nbsp; Our setup is not very complicated. &nbsp;I find it impossible to think Microsoft could not possibly have conceived of such a thing, and absolutely force you to use the local drive of every machine you log into.<br />
<br />
How does it work with ANY roaming profile scenario? &nbsp; Where users are wandering around to different machines? &nbsp; This is the same theory but much more simplified and therefore, in theory, easier to manage.... but it just isn't working.
</div>


<div>
You do not need OST files for this. Turn caching OFF.
</div>


<div>
@Malmensa: &nbsp;Now you are talking. &nbsp;But we absolutely do use roaming profiles. &nbsp;This is what I am talking about. &nbsp; I oversimplified my initial question because these factors are absolutely irrelevant but here we go again:<br />
<br />
I am moving the c:\users\%username%\appdat<wbr />a\microsof<wbr />t\outlook OST file created by default to:<br />
<br />
\\servername\TSRedirected\<wbr />%usersname<wbr />%\appdata\<wbr />Microsoft\<wbr />outlook &nbsp;&lt;----- Roaming profile.<br />
<br />
This does not work. &nbsp;The next day, some users Outlook 2013 mail profiles have been deleted automatically, replaced with a profile called &quot;Outlook&quot; and the data files are pointing back to c:\users\%username%\appdat<wbr />a\microsof<wbr />t\outlook again
</div>


<div>
@John Hurst: &nbsp; Turning off Caching sounds interesting mate, what will the downside be to users? &nbsp; Will they have to download their entire mailbox every time they log in? &nbsp;If not, where is the mail actually being stored? &nbsp;I have never turned caching mode off before.
</div>


<div>
On a workstation, there is no downside to turning off caching. <br />
<br />
They are on Exchange and just use their mail live. Assuming decent internet connection, it will not be a problem.
</div>


<div>
Apparently, cached exchange mode for RDS environments has been supported since Outlook 2010.....<br />
<br />
<a href="https://blogs.msdn.microsoft.com/rds/2010/09/14/announcing-support-for-cached-exchange-mode-in-a-remote-desktop-session-host-environment/" rel="ugc nofollow">https://blogs.msdn.microsoft.com/rds/2010/09/14/announcing-support-for-cached-exchange-mode-in-a-remote-desktop-session-host-environment/</a><br />
<br />
&quot;With Outlook 2010 in Cached Exchange Mode, the data store is accessed over the network rather than from a local hard disk. This scenario is only designed for networks that have high bandwidth and high levels of reliability. Keep in mind that this scenario causes all Outlook Disk I/O to be directed over the network. &quot;
</div>


<div>
@John Hurst: &nbsp; Thanks for this conversation mate, I really appreciate it. &nbsp;Need to hit this issue on the head quickly.<br />
<br />
My concern is that they are not using local Exchange. &nbsp; They are Office 365 users. &nbsp;Mail is in the cloud. &nbsp;Will they still not have to download everything every time they open outlook? &nbsp; From what I have read: <br />
<br />
&quot;Since no data is stored locally in Online Mode, Cached Exchange Mode increases the storage that is required for an Outlook 2010 deployment proportionally to the size of each deployed Exchange mailbox&quot;<br />
<br />
&quot;Since no data is stored locally&quot; scares me. &nbsp;If they are running a 5gb mailbox, how do they not have to download the whole thing every time? &nbsp;Not sure I understand how this works. &nbsp;Sorry :(
</div>


<div>
If you are using roaming profiles, you still point Outlook to an OST in the default location, inside of the user's profile on the local HDD. During the user login process, the entire profile, including the .OST is copied down from the network share to the local machine, I is copied back at logoff.
</div>


<div>
Outlook will not download the entire mailbox from a remote Exchange site. I have lots of users using remote Exchange. It could be a bit slower but that is better than corrupting OST files. &nbsp;(Not roaming profiles however).
</div>


<div>
Yeah, Microsoft support .PSTs and OSTs over a LAN, but as the statement above alludes to, it can be problematic. Having been burned a few times, I would only do this is the file server and TS boxes were running as VMs on the same host, where speeds are high and cabling issues non existent.
</div>


<div>
@John Hurst: &nbsp; I still don't understand how a 5gb mailbox that copies nothing onto any local machine does not have to download the mail that the user wants to read....... but I will give this a crack with a few users to see how it goes.
</div>


<div>
The connection from the workstation is live to the Exchange server. It is only dealing with the email of the moment. &nbsp;I didn't say &quot;nothing will be downloaded&quot; only that the 5 GB mail file will not be downloaded.
</div>


<div>
@John Hurst: &nbsp; I spoke to a colleague here and from what I understand, you see your entire mailbox as something of a contents page. &nbsp;Then it downloads the specific mail items that you specifically request when you click on them.<br />
<br />
If that's the case, I understand it now, but it looks like it will be a massive issue if their internet drops out at any point.
</div>


<div>
I suggest you try on one machine (test) and see how it works. If you are correct, even local Exchange would bog right down and in my experience it does not.<br />
<br />
The other way is to use local OST file as Malmensa and I both suggested.
</div>


<div>
I can see what Malmensa said about copying the OST back and forth when the user logs in and out, it just feels to me like this is going to cause more headaches than it resolves. &nbsp; <br />
<br />
-Users will take much longer to log in. &nbsp; <br />
-Files might not copy correctly and throw up all kinds of errors. &nbsp;<br />
-Sessions may crash out while the copy is happening in the background.<br />
-Users who accidentally log off while have to wait ages to log back in again as the OST file copies up to the network location, and then back down again.<br />
<br />
Just seems really messy, and if it can work this way, why can't I just sit the OST file in the roaming profile and point to it. &nbsp;This just makes sense and I am having a lot of trouble understanding why Microsoft make such a big deal out of it.
</div>


<div>
For 15 years I have been working with this stuff, Microsoft has never supported OST or PST files on a network shared. Invariably it leads to corruption.
</div>


<div>
Yep, that is a downside to roaming profiles. Probably slightly less evil that accessing .PSTs over a LAN though. <br />
<br />
Running without a local .OST file can work, but some operations are slower, while others speed up. If a user opens a 5Mb PDF in their email, it is downloaded at the time, so there is a noticeable delay. On the other hand, searches are much faster, and forwarding a 5Mb PDF to another user is also faster. <br />
<br />
On a terminal server, .OSTs can also quickly chew up a heap of disk space, With two TS boxes and a machine hosting roaming profiles, each user's 5Gb mailbox chews up 15Gb. With 20 users that s 300Gb more to store and backup each night; it is not uncommon for email to account for well over half of the disk space on the TS boxes.
</div>


<div>
Thanks for the info guys, you have both been brilliant. I have spoken to the client and we are trialling the turning off of caching for two users for a few days, these are key decision making users so we will see what the feedback is.<br />
<br />
Just so glad to have some potential resolution in progress as this was really causing me some frustration, and making us look bad at the same time!
</div>


<div>
I have got some feedback from the two test users guys, and it's not really looking good so far.<br />
<br />
This client is on a fibre connection, and running a speedtest confirms they are receiving 37mb downstream (which is epic in Australia). &nbsp; With this connection, I would expect users to hardly be able to notice they are using the cloud.<br />
<br />
What is actually happening, and I confirmed this myself by logging onto a users RDP session, is that when they open a simple email (no attachments), it takes 3-4 seconds to actually open. &nbsp;This is currently a terrible solution, and makes me even more appalled that Microsoft do not support the common-sense approach.<br />
<br />
Is there a reason why this is so slow on such a good connection? &nbsp;I guess what I am asking is: is this normal expected behaviour for turning off cached mode?
</div>


<div>
Update: &nbsp;The other user called me back so I could check with him too. &nbsp; &nbsp;His has actually reverted itself back from being online to c:\users\%username%\appdat<wbr />a and so on again.<br />
<br />
This means that this was not being caused at all by me centralising the OST location, it is being caused by some inherent failure of Outlook coding...... I have no idea how to stop this happening.<br />
<br />
I use the recommended method, Microsoft changes my settings back to local HDD again. &nbsp; This issue is brutal.
</div>


<div>
Does anyone have any ideas for this one? &nbsp; How is it still reverting back to local c: location for OST after I move him online?<br />
<br />
Why does this happen?
</div>


<div>
We still need a solution for this one.<br />
<br />
I cannot use roaming profiles, as Outlook will revert to using C:\ locations for some users (not all users, mind you. &nbsp; Some users are still pointing correctly to my redirected folders months later, GPresult /r for working users and non-working users is absolutely identical).<br />
<br />
I cannot use online mode as it takes users roughly 6 seconds to open a plain-text email with no attachments. (They have a dedicated 40mb fibre link that is quite fast and reliable).<br />
<br />
I cannot force users to use a particular server by customising RDP shortcuts because then there is no redundancy if a server fails. &nbsp;I can then also not perform unobtrusive maintenance tasks by disabling logins to a particular server.<br />
<br />
I cannot run a script that copies 20gb OSTs to and from the redirected folders every time they log in and out for obvious reasons.<br />
<br />
I am not sure what that leaves me with. &nbsp;I just leave it as it is with two locations for OST files and doubling up of the data? &nbsp;This is a terrible design, and must be a mistake.<br />
<br />
If I have left anything out that I have not tried yet, please let me know.
</div>


<div>
Probably not the solution you are after, but an onsite Exchange server would help a lot here. Rather than a 37Mb link to Singapore, you could easily have 1000Mb or more between Outlook and the mail server, making uncached mode run just fine.
</div>


<div>
The only solution to this issue was to give up.
</div>


<div>
<div class="content wysiwyg-content">
I am trying to move everyone over to a centralised roaming location for OST files.<br />
<br />
I am moving the OST file to the network location, deleting the existing mail profile, recreating the mail profile and pointing the data file to the network location.<br />
<br />
That works perfectly. &nbsp; I check back hours later and it is still working perfectly.<br />
<br />
Then the next day, I check back with a user and the mail profile I created has been removed completely and replaced with a default &quot;Outlook&quot; profile. &nbsp; The OSTs are pointed back to c:\users\..... again. &nbsp; I have been through every group policy object and there is nothing that points OST or PST files to the local hard drive.<br />
<br />
What am I doing wrong? &nbsp; How are they coming back? &nbsp; Why does Outlook 2013 do this?
</div>
</div>


I am trying to move everyone over to a centralised roaming location for OST files.

I am moving the OST file to the network location, deleting the existing mail profile, recreating the mail profile and pointing the data file to the network location.

That works perfectly.   I check back hours later and it is still working perfectly.

Then the next day, I check back with a user and the mail profile I created has been removed completely and replaced with a default "Outlook" profile.   The OSTs are pointed back to c:\users\..... again.   I have been through every group policy object and there is nothing that points OST or PST files to the local hard drive.

What am I doing wrong?   How are they coming back?   Why does Outlook 2013 do this?

Outlook 2013 Profiles

Microsoft Outlook is a personal information manager from Microsoft, available as a part of the Microsoft Office suite. Although often used mainly as an email application, it also includes a calendar, task manager, contact manager, note-taker, journal, and web browser.

Outlook

Office 365 is a group of software plus services subscriptions that provides productivity software and related services to its subscribers. Office 365 allows the use of Microsoft Office apps on Windows and OS X, provides storage space on Microsoft's cloud storage service OneDrive, and grants 60 Skype minutes per month. Office 365 includes e-mail and social networking services through hosted versions of Exchange Server, Skype for Business Server, SharePoint and Office Online, integration with Yammer, as well as access to the Office software. All of Office 365's components can be managed and configured through an online portal; users can be added manually, imported from a CSV file, or Office 365 can be set up for single sign-on with a local Active Directory using Active Directory Federation Services.