locked
Outlook 2010 creates new IMAP PST files at random and cannot send mail (roaming profiles and IMAP incompatible?) RRS feed

  • Question

  • This is a problem I've seen occur on several Windows 7 x64 PC's with Outlook 2010 32-bit. I really need to find the cause.

    The users are configured with one email account (IMAP), and since that cannot be the default PST, there's a default PST which contains contacts and calendar, but has no email account associated with it. Outlook will automatically create a local PST to associate with the IMAP account and name it "user@address.com.pst". At some point seemingly at random, the user will receive an error message when sending mail:

    "Outlook data file cannot be accessed (error 8004010F)"

    and any outgoing mail will be stuck in the Outbox of the default PST (not the IMAP PST, but the one that is not linked to an email account). If I check the data files, I will see that Outlook has created several new PST files associated with the IMAP account and named them

    user@address.com(2).pst

    user@address.com(3).pst

    user@address.com(4).pst

    etc. My only solution is to remove the IMAP account and re-add it, which will create another new PST and sync the mail.

    So my question is, what causes Outlook to randomly "forget" that an IMAP PST file is present and create a new one? How can I avoid this in the future? I found a KB article (http://support.microsoft.com/kb/2659085/en-us) mentioning that error message, but it only says that the profile may be configured incorrectly. Exactly what is incorrect?

    This isn't an isolated incident, as I've seen it happen on 4 out of 5 PC's that have been configured in this manner.


    • Edited by crhosu Tuesday, January 24, 2012 12:18 PM
    Wednesday, January 11, 2012 6:33 PM

Answers

  • I agree with you in that it's tied specifically to roaming profiles, and only after the user logs into more than one PC. It seems like the problem lies in that some of the Outlook settings, including the account settings and the location of the PST file, are in AppData\Roaming, while other files, including the PST itself, are in AppData\Local and don't roam. I don't understand why Outlook doesn't allow for disabling the local cache of an IMAP mailbox like other mail clients do. The PST is just a local cache of the master data, which resides on the mail server.

    I'm convinced that it's a bug in Outlook 2010, because the error says the data file cannot be accessed, but new mail is still able to be received in the IMAP PST. It's only the outgoing mail that fails.

    I've also yet to see anything documented by Microsoft that says IMAP and roaming profiles are incompatible.

    • Marked as answer by Tony Chen CHN Wednesday, February 8, 2012 12:59 AM
    Tuesday, January 24, 2012 12:17 PM

All replies

  • Hi,

    We have built a Gmail (IMAP) account in Outlook 2010 for testing and got this:

    1. Create new IMAP account, everything work fine
    2. Close Outlook, Remove .pst file, reopen Outlook, a new .pst(1) file create and can not send email with "Outlook data file cannot be accessed (error 8004010F)"

    We got the same result as you are encountered. Please understand this is IMAP rule by design that only the initial IMAP PST data file can be used.
    You may have a question how to move the IMAP personal folder PST if needed. While we don’t recommend moving the IMAP *.pst unless your drive space is tight, you can perform the following article to move the IMAP *.pst.

    http://www.slipstick.com/outlook/config/backup-config/how-to-move-the-imap-personal-folder-pst

    Hope the information blow could explain your concern. Feel free to post back. Thanks

    Tony Chen

    TechNet Community Support

    Tuesday, January 17, 2012 9:36 AM
  • In this case, the original .PST file is still present when Outlook decides to create a new one.

    Do you have any recommendations as far as the Indexing Service? The last time this happened, I tried to rename the old .PST file after Outlook created a new one, and I received a message about the .PST file being locked by the Indexing Service. Is it recommended to disable indexing of Outlook, or of .PST files?

    What would happen if the .PST file is locked by the Indexing Service when Outlook attempts to open?

    Tuesday, January 17, 2012 12:11 PM
  • Hi,

    We are also seeing a very similar issue, Outlook 2010(32 bit), Win7(64 bit), roaming profiles. Now have > 2500 machines built.

    Initial config: Exchange + IMAP account.

    User logs in to the first machine, accounts are configured and work. They then logout, this creates the server profile containing the accounts settings (users registry) but not the pst files which live in "users\<user>\appdata\roaming\local\Microsoft\Outlook".

    If they then login to any subsequent machines, Outlook settings are read from the user registry and Outlook tries to created the associated files. At this point there is a (high) possibility that they will get the "Outlook data file cannot be accessed (error 8004010F)" error when trying to send from the IMAP account.

    > "Please understand this is IMAP rule by design that only the initial IMAP PST data file can be used."

    This does not appear to be the case. After the first Send/Receive 8004010F error. If Outlook is closed and the imap pst file deleted. Outlook creates a new working copy on restart.

    I could set the imap pst to roam with the profile. Not an ideal option as the imap pst is often grater than 2GB. Login/out times can be in excess of 20 minutes. And there are a few thousand users. Does not scale.

    There is also the option of putting the pst on a server share, etc but this is not officially supported by Outlook and although it does work it eventually breaks with a corrupt pst.

     

    It appears that Outlook attempts to create the corret pst "imap.pst" but fails (some form of corruption, the pst is 265K, default size for an empty pst), it then tries to create "imap(2).pst". Again it fails (265K pst). However, the (2).pst file will populate at this point. It is just not able to send with the 8004010F error.

    ScanPST can also be used to reapir the pst but it does not fix it.

    Why does Outlook do this? If it is capable of creating a working imap.pst on the second run, why can't it do this initially?

    Any thoughs/suggestion?

    Thanks.




    • Edited by edkburns Tuesday, January 24, 2012 11:50 AM
    Tuesday, January 24, 2012 11:48 AM
  • I agree with you in that it's tied specifically to roaming profiles, and only after the user logs into more than one PC. It seems like the problem lies in that some of the Outlook settings, including the account settings and the location of the PST file, are in AppData\Roaming, while other files, including the PST itself, are in AppData\Local and don't roam. I don't understand why Outlook doesn't allow for disabling the local cache of an IMAP mailbox like other mail clients do. The PST is just a local cache of the master data, which resides on the mail server.

    I'm convinced that it's a bug in Outlook 2010, because the error says the data file cannot be accessed, but new mail is still able to be received in the IMAP PST. It's only the outgoing mail that fails.

    I've also yet to see anything documented by Microsoft that says IMAP and roaming profiles are incompatible.

    • Marked as answer by Tony Chen CHN Wednesday, February 8, 2012 12:59 AM
    Tuesday, January 24, 2012 12:17 PM
  • Good morning,

    I am experiencing a similar problem. I created two Gmail IMAP accounts in Outlook 2010 64-bit, running under Windows 7 Pro 64-bit. Everything works smoothly, I log out, log back in and I get the "Outlook data file cannot be accessed (error 8004010F)" error message. I also am unable to send messages.

    When I go to Account Settings/Data Files, I see that Outlook has created new .pst files for my IMAP accounts (*.pst(2) and *.pst(3)). I click on "Open File Location" (C:\Users\Ron\AppData\Local\Microsoft\Outlook) for one of the IMAP .pst files, and I file the original .pst files are still in place, and Outlook randomly created two additional .pst files for each IMAP account.

    I don't know what causes this behavior, but I am a longtime Outlook user, and this is the first time I've encountered a problem that renders the program essentially useless to me. Please note that I didn't remove the original IMAP .pst files at all. If there is a solution, I'm in line for it, and it appears I am not alone.

    Sunday, February 5, 2012 2:12 PM
  • 1. Are you using a roaming profile?

    2. Are you logging into multiple computers with that profile and running Outlook on each computer?

    Those two conditions together seem to reproduce the problem 100% of the time

    Monday, February 6, 2012 2:25 PM
  • Hi,

    I can confirm this happens every time when using roaming profiles with IMAP...

    It would be nice to have a solution.

    I will test with a pop account...

    Regards,

    Thomas

    Monday, February 13, 2012 10:22 AM
  • I think my co-worker has found a work-around for this problem:

    1. Log on to (virtual) machine #1.
    2. Create an email account.
    3. Log off from machine #1.
    4. Log on to machine #2.
    5. When you start Outlook it will create a foo@bar.com(2).pst.
    6. Exit Outlook.
    7. Start Outlook's Mail Setup (if you can't find it, look here).
    8. Click on the button Data Files.
    9. Select the mail account and click on Open File Location.
    10. Delete the foo@bar.com.pst (and not foo@bar.com(2).pst!).
    11. Rename foo@bar.com(2).pst to foo@bar.com.pst.
    12. (Still in Outlook Mail Setup) double click on the mail account, it will complain that foo@bar.com(2).pst can't be found.
    13. Select foo@bar.com.pst as the data file for this mail account.

    Happy roaming! ;-)


    • Edited by Theo Niessink Wednesday, February 29, 2012 4:20 PM Oops, forgot steps 12 and 13
    • Proposed as answer by Tony Chen CHN Thursday, March 1, 2012 9:25 AM
    Wednesday, February 29, 2012 4:15 PM
  • Based on some quick tests, the steps posted by Theo Niessink work in our environment.  While I've not gone past this test, I'd like to point out some caveats to this approach that I think might exist.

    • I believe one has to do this for each user, for each of their email accounts, for each machine they roam to.  This sounds monumental - in certain contexts - but it might actually be what we adopt for the time being (EXTREMELY small number of Outlook users and computers).  It would be interesting to see if steps 7-13 might be able to be automated (assuming Outlook is simply looking in registry settings).
    • These IMAP pst's would then accumulate wherever the user logs on and uses Outlook.  Assuming, for example, a huge gmail account accessed via IMAP in Outlook, this could be a couple of Gb's replicated on different computers.  Problematic or not?  Depends on your situation, I'd say.
    • If you used a GPO to routinely delete older copies of roaming profiles on system bootup, you'd have to do this process (steps 5-13) all over again for those machines where the local copy of the roaming profile was cleaned up.
    • These IMAP pst files won't be backed up if we're only backing up the server files.  Perhaps not a problem if all the real data is on the gmail servers (i.e. if we have to start from zero, these IMAP files would just be recreated and repopulated from gmail...true???)
    • This addresses only the IMAP pst files

    We're just starting to use Outlook 2010 (we didn't use Outlook before) and currently our file "Outlook.pst" is in the documents folder hierarchy, which we've redirected to the file server.  This seems to be the big "no-no".  If I understand things correctly, in our configuration where our email accounts are all gmail accounts accessed via IMAP, this "Outlook.pst" file will not contain any mail items and I suppose should not grow too large. This is admittedly only an assumption.

    My questions at this point are:

    1. Will this "Outlook.pst" file actually grow large or not?
    2. Assuming it doesn't grow large, is the risk great to keep it on the server (I'm making the distinction here between small and large pst files - perhaps a false distiction?)  If the risk is great and the size is small, I'll just have it roam at logon/logoff time.
    3. If it DOES grow large, could this process outlined for the IMAP pst files work for the "Outlook.pst" file as well?
    Monday, May 21, 2012 2:14 PM
  • Let there be more light in this:

    When you configure Outlook 2010 for IMAP, Outlook creates 2 pst files:

    First one is for caching IMAP folders and is located in the folder:
    C:\Users\%USERNAME%\AppData\Local\Microsoft\Outlook\
    There is no problem with this file - when user log in to the another computer, it creates automatically and stores offline whole IMAP folders.

    Second one holds user's Address book and Outbox folder and is located here:
    C:\Users\%USERNAME%\Documents\Outlook Data Files\
    this file replicates itself trough the roaming profile and if this file is created with account on another machine, then user gets the error with message sayng, that the file is inacessible and user cannot send mail. After logging on the original machine, where account was created, Oulook normally works again as before.
    I tryied to move this file to the some network share, it works, but the same error message is displayed cca 1 time daily, after restarting the computer Outlook works normally.

    I think, that there is some bug in Outlook, whis causes that issue.

    Any feedback from Outlook 2010 developer team?

    Thanks,
    Andy

    Thursday, May 24, 2012 7:58 AM
  • Just to throw more complexity into this, we've thrown Google Apps Sync into the mix!

    We have 4 users who share 2 computers (any one of them on either of the computers).  They each have an individual email address (Google Apps Educational account) and a "group" address that they can all monitor.  Here's how we've set it up (and hope it will work for us):

    1. Machine 1 - Create a profile for their individual address in Outlook using Google Apps Sync (this ends up being a MAPI address whose data is stored in a series of related files in \Users\<user>\AppData\Local\Google\Google Apps Sync)
    2. Machine 1 - In Outlook (in the profile created in step 1), create an IMAP account of the "group" address
    3. Machine 2 - Create the same profile as in step 1 using Google Apps Sync
    4. Machine 2 - In Outlook (in the profile created in step 3), create an IMAP account of the "group" address
    5. Machine 2 - Exit Outlook
    6. Machine 2 - Rename the files created in step 3 to match the name of those created in step 1 (there is a "key" value at the end of the file names that Google Apps Sync apparently uses)
    7. Machine 2 - Follow the steps outlined by Theo Niessink in the post above to "re-sync" which local PST file is used for the IMAP "group" mail account
    8. Test on both machines.

    It's NOT been smooth to setup and my "mileage has varied" between the setup for my 4 users!  I'd hate to expand this solution over more users as it's so squirrely to set up.  If the actual usage is problematic we'll have to scrap it as a solution and try something else (Thunderbird - but you loose a lot of Office integration and other niceties of Outlook OR something like SoGo - but it requires Samba4 which is a bit too bleeding edge for me at the moment...especially since we're on Samba3).

    Frankly, for the tiny non-profit organization, Outlook's promise is dimmed because of how it doesn't play nicely with a network environment if you don't have Exchange - which of course may be the WHOLE point right there!
    Friday, May 25, 2012 9:23 AM
  • I tryied to move this file to the some network share, it works, but the same error message is displayed cca 1 time daily, after restarting the computer Outlook works normally.

    The dev team will say that PST files are not supported on network shares. They can get quite large - that's a lot of network traffic, plus PST files are locked when Outlook opens them, so only one Outlook can use a pst at a time. A lost network connection can corrupt the pst file, resulting in data loss.


    Diane Poremsky [MVP - Outlook]
    Outlook Daily Tips | Outlook & Exchange Solutions Center
    Subscribe to Exchange Messaging Outlook weekly newsletter

    Friday, May 25, 2012 1:57 PM
  • Frankly, for the tiny non-profit organization, Outlook's promise is dimmed because of how it doesn't play nicely with a network environment if you don't have Exchange - which of course may be the WHOLE point right there!

    Outlook works fine on networks without Exchange - trying to roam the pst files is the problem.

    Have you priced Office 365 accounts? I'm not familiar with the EDU or non-profit pricing with either company, but office 365 retail pricing is 6 and 8 monthly (for P and lowest priced E plan), which is a little more than google's $50/year, but the experience is better - no sync app, everything just works. You also get a SharePoint site. The 'group' mailbox should be free on Office365.



    Diane Poremsky [MVP - Outlook]
    Outlook Daily Tips | Outlook & Exchange Solutions Center
    Subscribe to Exchange Messaging Outlook weekly newsletter

    Friday, May 25, 2012 2:09 PM
  • Diane,

    Thanks for weighing in on this.  My follow-up question to your response would be, if only keep messages in the local IMAP folder and have no POP accounts, does the Outlook.pst file also get enormous?  It would seem to me that roaming ONLY this pst file would not be as problematic either from the standpoint of making it part of the itinerant profile (that which actually gets moved to the local computer on login) because its size isn't too big OR using folder redirection to point to it on a server share.  Any thoughts about these scenarios specifically?

    Thanks,

    David

    Monday, May 28, 2012 7:12 AM
  • Indeed Outlook works fine in a network environment without Exchange if one assumes that a user never changes computers and needs the see the same Outlook environment on different computers.  It's there where we're groping for a solution.

    I've looked briefly at Office 365.  We have a Google Apps Education account (which is Google Premium for free, basically) and definitely have a minimum cash-flow outlay approach to most things here at our small private school where most folks are also volunteers.  That's an approach which certainly could be questioned, and if so, subsequent questions like using Office 365 could also be posed.  For the moment, however, keeping with the free/open-source/volunteer-based solutions makes even something priced like Office 365 a difficult solution to propose.

    Monday, May 28, 2012 7:25 AM
  • If the local pst file only has calendar, contacts, tasks and a few messages you don't want on the imap server, it should work better. You will still have problems with the pst file in use if they log into another computer while still using the current one.

    I guess terminal services / remote desktop is out of the question? That would eliminate most of the pst error problems but is not an end-all-be-all unless they work 100% in terminal services, which isn't always fun either.



    Diane Poremsky [MVP - Outlook]
    Outlook Daily Tips | Outlook & Exchange Solutions Center
    Subscribe to Exchange Messaging Outlook weekly newsletter

    Monday, May 28, 2012 5:52 PM
  • @Diane: yes, thats right, "local pst file only has calendar, contacts, tasks" and the Outbox folder, which is used to store messages only during sending of message. But there is still an issue, that sometimes some users creates new message, trying to send it, Outlook displays error saying, that Outlook cannot send message, message cannote be saved to drafts, restart of Outlook does not help, neither restart of whole computer solves the problem.

    Terminal services is not solution for us.

    We are using Outlook many years from version 97 to 2007 without problems with roaming profiles, only 2010 causes problems.

    Thanks,

    Andy


    • Edited by Andy V7 Tuesday, May 29, 2012 7:31 AM
    Tuesday, May 29, 2012 7:31 AM
  • When you get that message that Outlook can't send, does it apply just to the specific message you were working on or all message, meaning the pst file is corrupt?

    Is the pst file in the roaming profile or just in a network share? If you are roaming the pst in with the profile, storing it on a network share outside of the profile might work better.



    Diane Poremsky [MVP - Outlook]
    Outlook Daily Tips | Outlook & Exchange Solutions Center
    Subscribe to Exchange Messaging Outlook weekly newsletter

    Tuesday, May 29, 2012 12:21 PM
  • Well now then there yet...

    After long, hard work to get the permission to use roaming profiles at my company, I implemented them.

    I thought now's the time to convert our e-mail accounts off of the terminal server and just put them on everyone's account, via IMAP... Works great, until they log off and 'delete local cached copies of roaming profiles' runs. Argh.

    I even tried using a symbolic link: imap@account.com links to c:\users\whomever\Documents\Outlook Files\imap@account.com

    It works, until they log off. Great. I'd say bug in Outlook 2010.

    Friday, July 27, 2012 2:13 PM
  • Diane,

    I don't think TS/Remote Desktop services would resolve the issue. Any properly designed TS solution is based around stateless servers by definition, so some sort roaming user environment is always in place. And if we look at the OP's problem, it's the roaming profile that causes the headaches. TS would just move the issue from the desktop to the terminal session imo. And, in a reversal conclusion, any solution to the problem in TS would also work on fat clients with roaming profiles.

    Just my $.2 here.

    Dan


    On a clear disk you can seek forever.

    Tuesday, November 6, 2012 2:38 PM
  • Hello,

    Is there an issue for this problem ?

    Henri

    Tuesday, January 22, 2013 9:49 AM
  • I have come up with a temporary solution. I say temporary because it involves redirecting the pst files to a network share, which is not recommended by MS.  That said, our users have not had any issues with their personal/archive pst files being on a network share as long as the PC they are working is local to the network share, i.e. in the same building on the same local network.

    We have several users that share systems, some physical, some virtual, set up with roaming profiles.  We ran into the situation described above when one of the users needed to access a gmail account via Outlook 2010.  Along with roaming profiles, the users are in a GPO which enforces folder redirection, so the server share was already set up..

    \\ServerName\GPO_Redirect\%username%

    I added the Outlook2010 ADM (outlk14.adm) to the GPO, and enabled... "User Configuration/Administrative Templates/Microsoft Outlook 2010/Miscellaneous/PST Settings/Default location for PST files" ...and set the value to \\ServerName\GPO_Redirect\%username%\OutlookPSTRedirect

    I had to remove the existing IMAP account from Outlook and readd it. Doing so created the "OutlookPSTRedirect" folder automatically under the user's network share and the username@gmail.com.pst file was created there. Everything seems to be working fine after multiple logoffs and logons to different systems. No (2), (3), (4), etc. file versions are being created, messages do not get stuck in the outbox, folder view settings are remembered, etc., etc.

    Apparently you can also set the "ForcePSTPath" registry value manually, but I have not tested that.

    Tuesday, February 19, 2013 4:28 PM
  • ms people a pathetic Morons
    Friday, October 11, 2013 6:42 AM
  • I work at a small company of 15 users and I am sick and tired of deleting and recreating Outlook profiles to fix this problem as has been outlined above. MS developers and their managers are not pathetic morons. They cant be because they are brain-dead.

    • Proposed as answer by conanth Wednesday, January 22, 2014 9:35 AM
    • Unproposed as answer by conanth Wednesday, January 22, 2014 9:35 AM
    • Edited by conanth Wednesday, January 22, 2014 9:44 AM
    Wednesday, January 22, 2014 9:31 AM
  • I'm replying two years later just to mention that in one of my environments, pre-Exchange, we had all users Outlook.pst files on their network share (domain).  What inevitably happens is that the Outlook file splits so you'll have Outlook happily using say, Q:\OutlookFiles\outlook.pst, then on a Tuesday for example without warning the user finds that they can't see anything in sent items or inbox that date back to Monday or earlier.  You look at Dat Files for the mail profile and you see that there's now a new PST generated on c: in the default location Outlook would create one, and your Q: drive one.  I"m not sure what causes this, but that is irrelevant.  If Microsoft says something is not supported, don't waste time trying to make it work, that is just futile.  Even if you get it working perhaps after great effort, some new Windows Update or SP will go and muck it all up again, changing how things work so you're stuck re-inventing your solution.  

    Saturday, May 10, 2014 1:17 AM
  • Correct. FWIW, the cause is a disruption in the connection to the server - outlook will either stop working or create a new data file.


    Diane Poremsky [MVP - Outlook]
    Outlook & Exchange Solutions Center
    Outlook Tips
    Subscribe to Exchange Messaging Outlook weekly newsletter

    Saturday, May 10, 2014 1:23 AM
  • I finally did the following and fixed everything:

    1.  Go to C: > USERS > (User Name) > APP DATA > LOCAL > MICROSOFT > OUTLOOK and

        COPY (BACKUP) the affected .pst file to another Drive.

     

    2.  IN OUTLOOK:  FILE > ACCOUNT SETTINGS > REMOVE the affected Email Account.

     

    3.  CLOSE OUTLOOK.

     

    4.  C: > USERS > (User Name) > APP DATA > LOCAL > MICROSOFT > OUTLOOK and

        Delete .pst (and .ost) files.

     

    5.  OPEN OUTLOOK and RE-ENTER /SET-UP the Email account.

     

    6.  IF NECESSARY (folders/contents do not re-appear), replace .pst file with BACKUP copy

         (DO NOT RESTORE/REPLACE .ost file)

     

    7.  TEST SEND & RECEIVE.

     

    8.  DELETE BACKUPS AFTER ALL GOOD.


    Sunday, March 8, 2020 10:23 AM