Splitting Outlook data files on two separate drives?

[YeOldeStonecat]

Nothing trumps field testing over the long term, and in multiple environments.

I agree with this statement. Thus, in my ~30 year experience, I agree with Microsoft, as...I've run across plenty of situations where keeping "live" PST files across a network result in calls/problems.

Sure, things like server specs, network speeds, size of the PST, specs of the client workstation, what else is the server running, now many clients are connected to the server, what else are clients connecting to, how is the antivirus configured on workstations and server, file/process exclusions, etc etc etc etc...//gasp for air........etc etc some more.

I've witnessed these issues plenty of times. And...gone in and fixed them plenty of times.

 

[britechguy]

@callthatgirl: Well, it's become clear over time that you and I have very different limits and approaches regarding what "highly irregular" things we will consent to do and under what circumstances.

I don't think that any one of us here, or even an end user who knows their file resides non-locally, fails to understand if the network goes down then access to any file that does not reside locally goes down. At one point or another, probably everyone who uses computers has experienced a network outage of one form or another. They're familiar.

I certainly wouldn't consent to a setup where a PST is on a network where it would ever be accessed off-site via VPN and you've seen what I say about email hoarding - I won't do much work that supports the retention of everything, from everywhere and every time, forever. If you can't "look and toss" for things that you know are junk, I'm not going out of my way to create a situation where I have to keep fixing and fixing and fixing again and again. You look at that as a business opportunity (which is fine); I look at it as an unending hell that could be resolved via a necessary behavior change.

Any recommendations are subject to the end user being willing to follow them, or a tech being willing to follow them. My main point is that I am not a slave to recommendations that I have every reason to suspect are really not necessary. Having a PSD on an NAS that's in the same place that the end user always sits and uses Outlook, which is a very common thing in businesses, doesn't frighten me at all whether MS recommends it or not.

There are other recommendations, like never using registry cleaner utilities, that are the equivalent of the 10 Commandments for me.

 

[britechguy]

I've witnessed these issues plenty of times.

OK, I will not argue that as a general statement.

But clearly you, and the specific client you reference, have never encountered any of these in the ecosystem they've had active for a very long time. That's enough for me to say, "If it ain't broke, don't fix it," in that specific context.

There are plenty of things I would not set up were I doing the initial setup, and Outlook files across networks is one of them. But if I inherit a situation where tranquility has reigned for years, nor am I going to arm twist to change it. I might mention (as you did) that MS doesn't recommend the configuration as it exists, but once the client is making an informed decision in light of that, and their actual experience, that's their choice to make.

Were circumstances on the ground to change, and there was sudden and constant breakage and putting out of fires, then I'd insist on a change or fire the client.

Actual conditions dictate my courses of action more than anything else. I've seen some really off-the-wall stuff work, and work beautifully, and I'd rather cut off my right arm than fiddle with it. Don't mess with a working system that is, based on history, unlikely to fail is one of my core philosophies, and not just with computers. I've seen way more misery in the IT world and the automotive mechanics world caused by an inability to leave well enough alone and to constantly engage in "while I'm in here, even though things are fine" compulsion to make tweaks. No, thank you.

 

[YeOldeStonecat]

But clearly you, and the specific client you reference, have never encountered any of these in the ecosystem they've had active for a very long time.

Client(s)...plural..when referring to running into this situation.

Many things related to computers....can run in an unsupported setup OK for say, 90% of people. or say, 95% of people. But that 10, or 5, or 15...%...to me, that's not acceptable. Clients data is at risk! Regardless of it's just Outlook email, or...say, an accounting database. Quickbooks does not recommend, nor support, running their application across a VPN tunnel with the QBW file on the other end. Quickbooks is also, like Outlook, a very "chatty" (inefficient) database program. It sticks lots of fingers into the database. There's a chance of database corruption when running Quickbooks through a VPN tunnel in a typical fat client situation. Sure, it may work for 99% of users. But say..for 1% of users, the QBW file may corrupt. And that can get messy..and expensive, to repair.

I know, I know, we're talking about Outlook, not Quickbooks here.
But from my perspective, I'm supporting business clients. Not a stand alone home user. But since we're talking about keeping PST files across a network, onto a server, I'll go out on a limb and state we're talking about a business client here, not a home user. Although, well, you know my views on businesses and email...businesses should not be dealing with POP (nor IMAP) email here. But...sticking to topic of the thread...storing a PST on a mapped (or UNC path) network drive...
*Strains both the workstation (since Outlook itself will go into contention trying to work with a chatty database). Outlook can go into "not responding" more often.
*Strains network traffic...clogs up the network with heavier traffic, when the lanes on the network should be kept clear for other applications...so many PST files store on a server could really bog down larger more important LOB software.
*Strains server performance...there's a thing that greatly impacts server performance for a network..."TCQ"...Tagged Command Queue. The drives should be able to focus their energy on bigger things like LOB apps, and PST files...with their very chatty connection to Outlook, eat up TCQ cycles like a room full of PacMen gobbling up the dots.
*Antivirus software that should scan the mailbox....done from the client side...won't be able to properly read the PST. Antivirus software from client workstations should never..ever..scan mapped network drives anyways. This burdens the AV software of the server.
*Due to inefficiencies of the Outlook to PST connection when across a network, even when end users close Outlook at the end of the day...the file connection will often stay active to the PST on the server. Backup software on the server won't grab the PST properly (cleanly)...seen that many times.

Just because it will often work, doesn't mean it should be done.

 

[britechguy]

Clients data is at risk!

If, as you say, they have an appropriate backup protocol in place then, no, it really isn't. And when it comes to email, unless absolutely forced, I will not support POP at all because of its inherent dangers for data loss at the local level even with an appropriate backup protocol in place.

Server side protocols like IMAP and Exchange simply reconstruct the inbox (and any other server side folders, rules, etc.) if the local world blows up.

 

[britechguy]

businesses should not be dealing with POP (nor IMAP) email here

I'll absolutely agree about POP. No one should be using any service that might still exist that's POP only.

I have no issue with IMAP, philosophical or technical. It's worked beautifully every time I've encountered it, including under Outlook, for years now. But my contact with IMAP and Outlook is for home and very small business users, none of whom, ever, get anywhere near to the absolutely "ginormous" email database size limits that Outlook has by default.

I'm also of the opinion, and have stated it, that email is not intended, and should not be used as, a perpetual filing cabinet for anything and everything. "Small stuff" that you are likely to need later, even much later, is fine to keep around. Anything that's "read and addressed" should be immediately deleted after the "addressed" part has occurred. Anything that involves huge attachments should be offloaded out of email entirely into a personal archive, which is far more stable and unlikely to have any accidental corruption over long periods of time.

I don't keep supporting cyber-hoarders who will not change their practices and where the same issues are on "lather, rinse, repeat," cycles. For me (and that's a critical proviso) doing so is the very definition of insanity.

 

[callthatgirl]

@britechguy as I'm 100% working with Outlook clients all day and have been a tech for 27 years, my comments are valid for others to learn from, even though you consider your opinion valuable. I only participate in posts looking for advice, in my wheelhouse.

 

[britechguy]

my comments are valid for others to learn from

Who ever said or implied they weren't. Certainly not me.

This is not a pissing match, and I have no intention of starting one.

 

[Sky-Knight]

I have to say, I have one client that has been flouting this "rule" for years without problems. They have been on M365 for 6 (?) years now (previously on an in-house Exchange server), but have been doing local archiving of email for 20-some employees for 20 years, storing those PSTs on a network drive. Depending on the volume, they create new archive files once a year or so to keep them from getting too big, but at least a handful of those files are 10GB.

They have rebuffed multiple pleas to stop this practice, but it has never caused problems, and they have good backup, so on it goes.

There's what works, and there's what's supported. PST files are databases, and operating them over a network creates the risk of a connection problem corrupting the PST file. This can cause long Outlook start times as it attempts to fix the PST file over the network. If using gigabit... that's actually almost the same performance as locally attached if it's SATA. Still, not ideal.