Outlook .pst folder redirection possible?
-
@dafyre said:
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
@dafyre said:
At my last employer, we did store the PST files in the End-User's Redirected Documents folder. To my knowledge, we never had any Outlook issues that were caused by that.
If they are small, the network is fast and the NAS never disconnects, it often works.
We were ~250 users, most of them were redirected to a home folder on the SAN. The network was 1gig, and we did have problems, but by and large, the Exchange bits and the Home Folder bits were reliable.
Home folders on a SAN? We've seen people do this with smaller Drobo units but it's awkward. You have a LUN per user and iSCSI on the desktop? I've worked in a few places doing this but never on any scale (like a dozen users tops and very special user cases.)
Yes Home Folders on the SAN. One big iSCSI LUN connected to a Windows Server Failover Cluster for the SMB share of \server\homefolders... The full path was \server\homefolders\username.
It was a single LUN (3TB, IIRC). Not a LUN per user... that's just nuts!
An so the home folders are actually on a fileserver and the fileserver stores on a SAN.
One LUN per user is actually a standard way to handle certain things. Not common, but not unheard of. The Netgear SC101 SAN was designed for exactly this.
-
Replied.
Head got stuck in PowerShell coding... I'll check back again in a bit. -
@dafyre said:
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
@dafyre said:
At my last employer, we did store the PST files in the End-User's Redirected Documents folder. To my knowledge, we never had any Outlook issues that were caused by that.
If they are small, the network is fast and the NAS never disconnects, it often works.
We were ~250 users, most of them were redirected to a home folder on the SAN. The network was 1gig, and we did have problems, but by and large, the Exchange bits and the Home Folder bits were reliable.
Home folders on a SAN? We've seen people do this with smaller Drobo units but it's awkward. You have a LUN per user and iSCSI on the desktop? I've worked in a few places doing this but never on any scale (like a dozen users tops and very special user cases.)
Yes Home Folders on the SAN. One big iSCSI LUN connected to a Windows Server Failover Cluster for the SMB share of \server\homefolders... The full path was \server\homefolders\username.
It was a single LUN (3TB, IIRC). Not a LUN per user... that's just nuts!
OK now that we know that it's a fileserver, why did you mention that it was SAN?
-
@Dashrender said:
@dafyre said:
@scottalanmiller said:
@dafyre said:
@scottalanmiller said:
@dafyre said:
At my last employer, we did store the PST files in the End-User's Redirected Documents folder. To my knowledge, we never had any Outlook issues that were caused by that.
If they are small, the network is fast and the NAS never disconnects, it often works.
We were ~250 users, most of them were redirected to a home folder on the SAN. The network was 1gig, and we did have problems, but by and large, the Exchange bits and the Home Folder bits were reliable.
Home folders on a SAN? We've seen people do this with smaller Drobo units but it's awkward. You have a LUN per user and iSCSI on the desktop? I've worked in a few places doing this but never on any scale (like a dozen users tops and very special user cases.)
Yes Home Folders on the SAN. One big iSCSI LUN connected to a Windows Server Failover Cluster for the SMB share of \server\homefolders... The full path was \server\homefolders\username.
It was a single LUN (3TB, IIRC). Not a LUN per user... that's just nuts!
OK now that we know that it's a fileserver, why did you mention that it was SAN?
The SAN is where the User Home Folders lived. The File Server connected to the SAN, and shared out the "HOMEFOLDERS" folder from the SAN Lun.
Edit: Going AFK a bit. I'll catch up soon.
-
@dafyre said:
The SAN is where the User Home Folders lived. The File Server connected to the SAN, and shared out the "HOMEFOLDERS" folder from the SAN Lun.
I get that it is where the bits end up. But the file server is how it is normally said that they "live." They have SMB Shared that they are on from a file server. The file server stores its one filesystem on a SAN, the folders themselves do not "exist" there. The SAN cannot see or read them or manipulate them. To the SAN it is just a LUN. It is the file server that takes that raw block device of SAN, DAS, or just disks and turns it into home folders and such.
If it wasn't a SAN but was just disks, would you say that the home directories were on disks instead of on a file server? No different.
-
@scottalanmiller said:
@dafyre said:
The SAN is where the User Home Folders lived. The File Server connected to the SAN, and shared out the "HOMEFOLDERS" folder from the SAN Lun.
I get that it is where the bits end up. But the file server is how it is normally said that they "live." They have SMB Shared that they are on from a file server. The file server stores its one filesystem on a SAN, the folders themselves do not "exist" there. The SAN cannot see or read them or manipulate them. To the SAN it is just a LUN. It is the file server that takes that raw block device of SAN, DAS, or just disks and turns it into home folders and such.
If it wasn't a SAN but was just disks, would you say that the home directories were on disks instead of on a file server? No different.
Right. I was being extra verbose to make sure everybody understands the route data takes from the user's roaming profile to get to its final resting place (the SAN).
-
@dafyre said:
@scottalanmiller said:
@dafyre said:
The SAN is where the User Home Folders lived. The File Server connected to the SAN, and shared out the "HOMEFOLDERS" folder from the SAN Lun.
I get that it is where the bits end up. But the file server is how it is normally said that they "live." They have SMB Shared that they are on from a file server. The file server stores its one filesystem on a SAN, the folders themselves do not "exist" there. The SAN cannot see or read them or manipulate them. To the SAN it is just a LUN. It is the file server that takes that raw block device of SAN, DAS, or just disks and turns it into home folders and such.
If it wasn't a SAN but was just disks, would you say that the home directories were on disks instead of on a file server? No different.
Right. I was being extra verbose to make sure everybody understands the route data takes from the user's roaming profile to get to its final resting place (the SAN).
I think our concern was the lack of verbosity as it left us unclear what was going on. Specifically in this case it made a pretty big difference because the reliability of a file server handling PST/OST and doing it to a SAN would be very different. The SAN plays no part of the relevance in the discussion in this case as it is behind the scenes and it is the file server that creates the concern.
There is no concern with putting PSTs on a SAN. So stating putting them on a file server, where there is concern, as putting them on a SAN because the SAN is backing the file server, isn't verbose enough.
@Dashrender pointed out that a lot of people were not aware that using SANs for home directories could be done or was done so that that might add to this seeming confusing to me and not to others. But we didn't mention that SANs are specifically a fix for file servers for PSTs and that was the original context here so really matters.
So just so people are aware: the concern with PSTs is with the SMB protocol. Using one LUN per user for home directories stored actually on a SAN is a known, while extreme, means of handling remote PST storage.
-
Where I work nobody delete e-mails.
I try to explain the problem with the size in Exchange but they just don't care.Only way I found to reduce the Exchange Database was use Pst, we have a lot, and many are really big.
I put all of them in an old server, 12 years old, It works perfect, no problems since I use this system.
-
@iroal said:
Where I work nobody delete e-mails.
I try to explain the problem with the size in Exchange but they just don't care.Only way I found to reduce the Exchange Database was use Pst, we have a lot, and many are really big.
I put all of them in an old server, 12 years old, It works perfect, no problems since I use this system.
Yeah no, that's a horrible process. If users are storing emails into PST files that are hosted on a network share, you might as well kiss that email goodbye.
PST are not designed to work over a network share. Period, never have been and likely never will be.
If you need an infinite amount of past email saved switch everyone over to OWA or a different platform.
-
@iroal said:
Where I work nobody delete e-mails.
I try to explain the problem with the size in Exchange but they just don't care.Only way I found to reduce the Exchange Database was use Pst, we have a lot, and many are really big.
I put all of them in an old server, 12 years old, It works perfect, no problems since I use this system.
Why not just let Exchange get bigger? How much are we talking per user? Average and worst case?
-
Policy is really the issue here. Set a mailbox limit and stick with it. Force users to clean out their old garbage. Chances are there is a ton of emails that can be deleted. Exchange is not meant to hold attachments, so all those emails should be deleted and their content should be stored on a user's network share.
-
@IRJ said:
Policy is really the issue here. Set a mailbox limit and stick with it.
If management wants large mailboxes and is the one paying for them, what's the concern?
-
@scottalanmiller said:
@IRJ said:
Policy is really the issue here. Set a mailbox limit and stick with it.
If management wants large mailboxes and is the one paying for them, what's the concern?
Then everything should be hosted on Exchange like you previously said. PST(s) are a sloppy way to archive especially if you are archiving for everyone and trying to move to network shares.
-
That's what we do. We have 50GB mailboxes (thank you Office 365) and everything goes on Exchange. That way you can use OWA. If you use PSTs you start to lose functionality or options.
-
@scottalanmiller said:
That's what we do. We have 50GB mailboxes (thank you Office 365) and everything goes on Exchange. That way you can use OWA. If you use PSTs you start to lose functionality or options.
One thing I'm finding is that the OWA search function is so much faster than even using a cached exchange connection in Outlook. What keeps me in Outlook proper is being able to select messages and drive it mostly from the keyboard. I cannot do this in OWA.
-
@dafyre said:
@scottalanmiller said:
That's what we do. We have 50GB mailboxes (thank you Office 365) and everything goes on Exchange. That way you can use OWA. If you use PSTs you start to lose functionality or options.
One thing I'm finding is that the OWA search function is so much faster than even using a cached exchange connection in Outlook. What keeps me in Outlook proper is being able to select messages and drive it mostly from the keyboard. I cannot do this in OWA.
OWA is better than Outlook, but users swear they need outlook. Even though most of our users don't even use a calendar...lol
-
@dafyre said:
@scottalanmiller said:
That's what we do. We have 50GB mailboxes (thank you Office 365) and everything goes on Exchange. That way you can use OWA. If you use PSTs you start to lose functionality or options.
One thing I'm finding is that the OWA search function is so much faster than even using a cached exchange connection in Outlook. What keeps me in Outlook proper is being able to select messages and drive it mostly from the keyboard. I cannot do this in OWA.
Searching is one of those things that tend to be way better server-side than client-side.
-
@IRJ said:
@dafyre said:
@scottalanmiller said:
That's what we do. We have 50GB mailboxes (thank you Office 365) and everything goes on Exchange. That way you can use OWA. If you use PSTs you start to lose functionality or options.
One thing I'm finding is that the OWA search function is so much faster than even using a cached exchange connection in Outlook. What keeps me in Outlook proper is being able to select messages and drive it mostly from the keyboard. I cannot do this in OWA.
OWA is better than Outlook, but users swear they need outlook. Even though most of our users don't even use a calendar...lol
And OWA Calendaring works decently, too.
-
I have been so accustomed to using the keyboard for my email, thanks largely in part to GMail, lol. I can tag and mark messages and all of that in GMail with my keyboard. I'd love to be able to do that in OWA / Office365. I really could ditch outlook then.
-
Can you not do that with OWA? I've definitely not tried, just wondering.
