SINC_dmack
asked on
Occasional PST corruption problems with roaming profiles. Alternative solution?
We have several clients who have IMAP email and access it using Outlook 2007 / 2010 / 2013 / 2016. Those clients have a TON of data in their PSTs and don't want to lose them. The clients have a TON of data in their email, so we've broken it up into archive PSTs by year. (IE, archive_2015.pst, archive_2016.pst, etc.) The default mail destination PST doesn't have anything more than about a year old in it. By doing so, this keeps the PSTs down to 2-3GB each.
The data in these PSTs is important and needs to be backed up locally and offsite. The servers at the clients' locations have local and offsite backups configured, so the trick was getting the PST files to the servers to they're backed up.
By default, Outlook stores the PSTs in %userprofile%\appdata\loca
Except there are problems with PST corruption. One of the clients had a couple of users that would get impatient during the logon / logoff process and forcibly reboot their computers. No surprise how the corruption happened there. But we have another user at a different client that also encounters corruption issues despite being patient and tolerant during logon and logoff. The corruption issues only seem to become noticeable after logon in the morning--if Outlook doesn't give errors in the morning, it'll be fine all day. This leads me to think that the corruption is happening during the logon / logoff process.
I know that Microsoft doesn't support running PSTs from network shares. But surely PSTs should be robust enough to survive the roaming profile process unscathed, right? (Assuming a healthy network infrastructure, of course.)
So, what's my question? I guess it's kind of open ended. Is putting the PSTs in the roaming profiles a big no-no? If so, what's another reliable alternative for getting PSTs synched out to the server so they're backed up locally and offsite? (Some of the workstations do have local backups but we don't want to have to rely on those.)
The data in these PSTs is important and needs to be backed up locally and offsite. The servers at the clients' locations have local and offsite backups configured, so the trick was getting the PST files to the servers to they're backed up.
By default, Outlook stores the PSTs in %userprofile%\appdata\loca
Except there are problems with PST corruption. One of the clients had a couple of users that would get impatient during the logon / logoff process and forcibly reboot their computers. No surprise how the corruption happened there. But we have another user at a different client that also encounters corruption issues despite being patient and tolerant during logon and logoff. The corruption issues only seem to become noticeable after logon in the morning--if Outlook doesn't give errors in the morning, it'll be fine all day. This leads me to think that the corruption is happening during the logon / logoff process.
I know that Microsoft doesn't support running PSTs from network shares. But surely PSTs should be robust enough to survive the roaming profile process unscathed, right? (Assuming a healthy network infrastructure, of course.)
So, what's my question? I guess it's kind of open ended. Is putting the PSTs in the roaming profiles a big no-no? If so, what's another reliable alternative for getting PSTs synched out to the server so they're backed up locally and offsite? (Some of the workstations do have local backups but we don't want to have to rely on those.)
Exchange Archive Databases would be the way to go.
The way roaming profile works, it loads data from network profile share when user logs on and sync back data when user logoff machine
Since you are directly storing PST files within user profile, it actually need time to download and upload changes. depending upon your network architecture, PST size, server load and machine performance from where roaming profile is syncing this time will vary.
Also note that PST sync is not block level but it will sync entire PST from client to server as change
If user close LID after logoff immediately before logoff process completed, PST corruption might occurs
If user kept machine locked some where and logged on another machine, still PST corruption can occur
The best option could be:
Deploy online archival solution \get archival solution from Microsoft O365 and remove PST entirely or keep PST out of roaming profiles locally on machine
Since you are directly storing PST files within user profile, it actually need time to download and upload changes. depending upon your network architecture, PST size, server load and machine performance from where roaming profile is syncing this time will vary.
Also note that PST sync is not block level but it will sync entire PST from client to server as change
If user close LID after logoff immediately before logoff process completed, PST corruption might occurs
If user kept machine locked some where and logged on another machine, still PST corruption can occur
The best option could be:
Deploy online archival solution \get archival solution from Microsoft O365 and remove PST entirely or keep PST out of roaming profiles locally on machine
ASKER
Exchange or Office 365 are not options. These clients are subscribing to cheap IMAP email hosting and it's unlikely that they'll be willing to significantly increase their email budget accordingly.
The PSTs are only synchronized with the server doing logon and logoff--these are roaming profiles, after all--so the PSTs shouldn't be locked. And no other files or databases are experiencing any kind of data issues. That's why I'm having a hard drive wrapping my head around the periodic corruption.
The PSTs are only synchronized with the server doing logon and logoff--these are roaming profiles, after all--so the PSTs shouldn't be locked. And no other files or databases are experiencing any kind of data issues. That's why I'm having a hard drive wrapping my head around the periodic corruption.
By default .PST files are not meant to be stored on a network anywhere. They should be stored on a local drive then synchronized after the user has logged off to avoid issues with file locks.
.PST files are very susceptible to corruption when stored on a network.
A KB to back this up ... no pun intended.
.PST files are very susceptible to corruption when stored on a network.
A KB to back this up ... no pun intended.
ASKER
Philip, what you describe is exactly what we are doing. Roaming profiles synchronize after the user is logged off, so there should not be any file lock issues.
PST file is like "Handle with Care" . As suggested by Steve, Using the Exchange or Office 365 as the main mail system will be the good option.
Just wanted to ask? What happens with the corrupt PST file?
Just wanted to ask? What happens with the corrupt PST file?
syncing the PST takes time, particularly when they are large and the user is a hoarder.
Unfortunately this doesn't tie up well with Outlook as they could attempt to open Outlook before the sync has finished,
More likely to be the issue however is that recent versions of Outlook don't actually 'close' when you click close. It continues to process and update the PST for a period afterwards. This is a real problem during logoff as it's trying to sync the PST via roaming profiles even though Outlook may not have actually closed it.
Additionally, the format of PSTs is not resilient at all. The slightest bit of corruption causes problems and results in loss of data.
Basically, what you're trying to do isn't supported and you are very likely to experience corruption if you continue.
Unfortunately this doesn't tie up well with Outlook as they could attempt to open Outlook before the sync has finished,
More likely to be the issue however is that recent versions of Outlook don't actually 'close' when you click close. It continues to process and update the PST for a period afterwards. This is a real problem during logoff as it's trying to sync the PST via roaming profiles even though Outlook may not have actually closed it.
Additionally, the format of PSTs is not resilient at all. The slightest bit of corruption causes problems and results in loss of data.
Basically, what you're trying to do isn't supported and you are very likely to experience corruption if you continue.
ASKER
Steve, we have the users' workstations set to log off at a scheduled time each night, to ensure that their roaming user profiles are synchronized with the server. You think that the users who are experiencing corruption are leaving Outlook open, and when the computer starts logging off and synchronizing the profile, Outlook is still running even though the GUI has been closed by the logoff process? So... if we ensured that Outlook was closed well in advance of the automated logoff, that might resolve the issue. Hmmm.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I've asked the users to make sure they close Outlook before they go home for the night (their workstations are scheduled to log off later on in the evening so that their profiles sync) and that seems to have resolved the corruption issues. On a couple of occasions, people have forgotten to close Outlook, and that's been the only times that PST corruption has become an issue any more. I guess we could look into seeing how to script / schedule Outlook being closed to ensure that it's not left open inadvertently.
Why Outlook apparently remains open, writing to the PST, for minutes or more after the GUI is closed, is beyond me.
I'm trying to get both of the clients to switch to hosted Exchange as a permanent solution, but they are hesitant to switch from janky $2/month IMAP mailboxes.
Why Outlook apparently remains open, writing to the PST, for minutes or more after the GUI is closed, is beyond me.
I'm trying to get both of the clients to switch to hosted Exchange as a permanent solution, but they are hesitant to switch from janky $2/month IMAP mailboxes.
ASKER
Thank you for your assistance and recommendations!
Ideally your PSTs wouldnt be needed as you would use a centralised mail system, like Gmail, Exchnage or Office 365. This means the PSTs (or OSTs on most cases) would simply be a copy of whats already on the server and would therefore already be duplicated.
if this isn't viable, replication/copying the PSTs is easy with many file copy programs, but you mus take the copy when Outlook is closed or it'll be a corrupted PST.
Thats the tricky bit.