PilotMelch
asked on
Outlook 2016 - open PST file - message "xxx.pst is not and Outlook data file (.pst)" - but it is
A customer has Office 365 and thus Outlook 2016 with all updates. Though she has Office 365, she uses Outlook only to access her Gmail account in addition to accessing old emails and old contacts that were long ago saved to two (2) independent .pst files, respectively. Everything worked fine until recently. She accessed her gmail, and had the two .pst files opened and accessible without problems.
Then 2 or 3 weeks ago when she opened Outlook she received an error message that the .pst files couldn't be opened (her words here, I don't have the specific error message unfortunately). Outlook still launched, but when she tried to access those PST files from the left folders pane as she normally would, she'd get that error message. So she closed them and tried to re-open (File/Open & Export/Open Outlook Data File... choose file, click [Open]). And gets the following error message:
"The <file path and name>.pst is not an Outlook data file (.pst)."
But of course it is a .pst file, both in name and contents, and has been used as one up until recently.
I of course can replicate this with both .pst files on her machine (a Surface 3, not that that matters)
I ran scanpst.exe on both and it found only minor problems, and I did the repair on those. On second, and third, and fourth.. run it finds nothing.
Thinking that perhaps the problem may be possibly a corrupt Outlook install, or perhaps an update (it was working fine until recently), I decided to try opening these files on a different computer with Office 365/Outlook 2016. Same problem.
These files I believe were originally created in Outlook 2007, but I am still at a loss for why that would matter. They were working just fine until a few weeks ago.
Did something change in Outlook 2016, perhaps in a recent update, that stopped supporting these files?
Both machines I tried the files on (and failed) were Windows 10, but again, both had been working on Windows 10 until a few weeks ago too. So I'm hesitant to think that has anything to do with the problem too.
* So, its two files, not just one
* Both files check out with scanpst.exe
* Everything was working until a few weeks ago, and then inexplicably stopped working
* Nothing is ever changed in these files (so I'm told). They are just old contacts and emails that are occasionally referenced
* The problem can be replicated on another machine with Outlook 2016 fully updated, and Windows 10 fully updated.
Any thoughts out there?
Then 2 or 3 weeks ago when she opened Outlook she received an error message that the .pst files couldn't be opened (her words here, I don't have the specific error message unfortunately). Outlook still launched, but when she tried to access those PST files from the left folders pane as she normally would, she'd get that error message. So she closed them and tried to re-open (File/Open & Export/Open Outlook Data File... choose file, click [Open]). And gets the following error message:
"The <file path and name>.pst is not an Outlook data file (.pst)."
But of course it is a .pst file, both in name and contents, and has been used as one up until recently.
I of course can replicate this with both .pst files on her machine (a Surface 3, not that that matters)
I ran scanpst.exe on both and it found only minor problems, and I did the repair on those. On second, and third, and fourth.. run it finds nothing.
Thinking that perhaps the problem may be possibly a corrupt Outlook install, or perhaps an update (it was working fine until recently), I decided to try opening these files on a different computer with Office 365/Outlook 2016. Same problem.
These files I believe were originally created in Outlook 2007, but I am still at a loss for why that would matter. They were working just fine until a few weeks ago.
Did something change in Outlook 2016, perhaps in a recent update, that stopped supporting these files?
Both machines I tried the files on (and failed) were Windows 10, but again, both had been working on Windows 10 until a few weeks ago too. So I'm hesitant to think that has anything to do with the problem too.
* So, its two files, not just one
* Both files check out with scanpst.exe
* Everything was working until a few weeks ago, and then inexplicably stopped working
* Nothing is ever changed in these files (so I'm told). They are just old contacts and emails that are occasionally referenced
* The problem can be replicated on another machine with Outlook 2016 fully updated, and Windows 10 fully updated.
Any thoughts out there?
I suggest trying to open file on another machine with working outlook ,if works fine re-install outlook!
The Outlook 2007 file could be the old (Outlook 2003) format but I thought Outlook 2016 could read these. Certainly Outlook 2013 could.
Back up the PST file for one account as backup.pst, delete the Outlook account and PST file (remember that you backed it up )
Now make a new account and import backup.pst. Can you import and correct the issue?
Back up the PST file for one account as backup.pst, delete the Outlook account and PST file (remember that you backed it up )
Now make a new account and import backup.pst. Can you import and correct the issue?
ASKER
aboo_s, thanks for the suggestion, but I've already tried that and detailed the results in my original post.
John Hurst, thanks for the reply. I backed up the only existing account (a gmail account) to a .pst file and then opened it separately without an issue. So, I am able to open a .pst freshly created.
Also, I'm pretty sure the .pst files I have here were created in at least Outlook 2007, given the vintage of the computer from which they were created originally. And they were created with an Export to .pst as well (account was an Exchange account, using .ost file locally of course).
Any other ideas?
Thanks.
John Hurst, thanks for the reply. I backed up the only existing account (a gmail account) to a .pst file and then opened it separately without an issue. So, I am able to open a .pst freshly created.
Also, I'm pretty sure the .pst files I have here were created in at least Outlook 2007, given the vintage of the computer from which they were created originally. And they were created with an Export to .pst as well (account was an Exchange account, using .ost file locally of course).
Any other ideas?
Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
PST files can be damaged from time to time, so if importing fixed it, then you have your solution.
ASKER
Yes, I understand pst files can be damaged, but that is what scanpst is for. As noted, I ran scanpst on these files several times, with only the first run noting any errors, and they were designated as minor. Nevertheless, even after scanpst (from the latest Outlook 2016) was run, these files would still not open. If they were damaged, they would have had to be damaged in a way that scanpst didn't recognize, and Outlook 2016 did, which seems just a bit odd to consider.
As noted, I have a possible solution for this case, at least the customer will be working again. However, we were unable to determine the actual problem/cause here. Doing so is really the only way to have a 100% solution, otherwise you don't know what problem you solved, whether you actually solved a problem or just got lucky, or if you just kicked the can a bit further down the road.
As noted, I have a possible solution for this case, at least the customer will be working again. However, we were unable to determine the actual problem/cause here. Doing so is really the only way to have a 100% solution, otherwise you don't know what problem you solved, whether you actually solved a problem or just got lucky, or if you just kicked the can a bit further down the road.
I was not lucky. Importing a PST file is a standard way to fix a file when SCANPST fails. I have done many of these.
ASKER
John, thanks for your help and support. Your suggestion was practical here, and was possible due to your experience and willingness to share it.
That said, in response, to you last thought doing something a lot still doesn't explain the problem, and thus we don't know if we "fixed" anything, really. We may have just made a symptom go away. One could even argue that having to do something a lot is evidence that there is indeed an unresolved problem.
Anyway, doing something a lot and having it make things better is worthy experience, but finding and fixing a problem, knowing that problem clearly, and taking steps to make it go away forever is the real "fix".
Simply put, if you don't know what the "problem" was, then you don't really know if you "fixed" the it. I'm using the real meaning of those terms, not the meanings for these terms that stand for I have a headache and I found a way to make it go away (again). The real meaning is that you found, clearly, an actual defect (bug, misconfiguration, incompatibility, etc.) that caused the symptom of a headache, and you devised a means, the "fix" to make the problem go away permanently, and deterministically.
I have nothing to indicate that this "problem" won't come up again. That is because we didn't actually find the "problem", understand it, and take steps to make it not be a problem anymore. Thus, it, whatever it is, is not "fixed".
For example, neither you or I can yet explain why the two pst's went bad, or if they themselves were even bad at all, or if it will happen again. I don't think you can assure me it won't happen again, right?
In this situation it is clear we made the only a symptom go away. The customer is back in business. That's all. But the real defect, or reason, that caused the issue in the first place is, well, unknown; and maybe not fixed at all. Or it may never happen again. Unknown is just that and nothing more; unknown.
That said, in response, to you last thought doing something a lot still doesn't explain the problem, and thus we don't know if we "fixed" anything, really. We may have just made a symptom go away. One could even argue that having to do something a lot is evidence that there is indeed an unresolved problem.
Anyway, doing something a lot and having it make things better is worthy experience, but finding and fixing a problem, knowing that problem clearly, and taking steps to make it go away forever is the real "fix".
Simply put, if you don't know what the "problem" was, then you don't really know if you "fixed" the it. I'm using the real meaning of those terms, not the meanings for these terms that stand for I have a headache and I found a way to make it go away (again). The real meaning is that you found, clearly, an actual defect (bug, misconfiguration, incompatibility, etc.) that caused the symptom of a headache, and you devised a means, the "fix" to make the problem go away permanently, and deterministically.
I have nothing to indicate that this "problem" won't come up again. That is because we didn't actually find the "problem", understand it, and take steps to make it not be a problem anymore. Thus, it, whatever it is, is not "fixed".
For example, neither you or I can yet explain why the two pst's went bad, or if they themselves were even bad at all, or if it will happen again. I don't think you can assure me it won't happen again, right?
In this situation it is clear we made the only a symptom go away. The customer is back in business. That's all. But the real defect, or reason, that caused the issue in the first place is, well, unknown; and maybe not fixed at all. Or it may never happen again. Unknown is just that and nothing more; unknown.
ASKER
Solved the problem using John Hurst's suggestion of trying to import the contents of the old .pst files into a newly created .pst file. The import succeeded.
However, we were not able to identify what the original problem was, thus I graded the solution as a B (but John Hurst's help an A) as there is still an unknown issue at work here.
However, we were not able to identify what the original problem was, thus I graded the solution as a B (but John Hurst's help an A) as there is still an unknown issue at work here.