Content search exported PST files showing wrong folder hierarchy and are not Importable to EXO mailbox!

Question

Hello Guys,

I think I found an Problem with the Content Search PST-Export and the PST-Import "Service" as well as Powershell "New-Mailboximportrequest" from own Azure Blob storage.

There is an Support-Case open, but I realy believe that they don't want or maybe can't help me. But it shows no process in about 2 Weeks now. The always ask me the same questions again and again.... Like they are not reading what I am writing. Thats realy exhausting. (the Case is [Case #:24556679] if someones interested)

Because of that I am writing here, to get some help, or just to reach people who can actualy do something to solve it.

I am an IT-Admin and migrating our company to an completely new Active-Directory Domain + New Tenant. The Admins befor did not realy have any glue what they did, and they messed up the whole AD-Config.
To get this all done with an minimum of User noticable impact, I think the PST-Way would be great for my situation.

So I started to do an Content Search in Tenant A and exported everything as PST-Files.

I choosed all settings which can be found in the help docs. I searched with "Exchange Online" only (No sharepoint etc marked) and it found the correct amount of mailboxes.

So I created the Export job with "One PST-File PER MAILBOX" and nothing more. The exported PST-Files all downloaded well and I startet to try the Import in Tenant B.

so the Transfer itself will happen like this:

Tenant A michael.hahn@company1.de to Tenant B michael.hahn@company2 .de

So first I tried with the known Import-Service and the config.csv file. The import itself worked. BUT even the Alias of the 2 mailboxes are identical, the Import was not able to match the existing Rootfolders correctly and imported everything inside the new Mailbox, but with the whole Root-Structure attached.

With EWS-Editor it looks like this:

What I think is happening here is somethink like the Import-Job ist not fully matched the to the Files which are exported with Contentsearch.

It looks like an Array. The Import-Job should look in the First key of the "Subarray" like ARRAY->[0]-SUBARRAY->DATA-TO-IMPORT

But instead it takes the "Array" and writes it to the completely wrong place.

This import was made for example with an Config like this:

Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,ContentCodePage,SPFileContainer,SPManifestContainer,SPSiteUrl
Exchange,,michael.hahn.pst,michael.hahn,FALSE,/,,,,

After that I tried it out with powershell and the pst-files hosted on an Azure-Blob storage. With commands like this:

New-MailboxImportRequest -Name "mailbox_import_testuser" -Mailbox "michael.hahn" -TargetRootFolder "/" -AzureBlobStorageAccountUri "...." -AzureSharedAccessSignatureToken "?sv=......."

The result was the same. It also ignores any try with commands like: -TargetRootFolder "/" -IncludeFolders "#INBOX#"

The names of the added Folders are messed up too. It looks like there is just the next foldername added to the firstone

like the imported INBOX shows the Name "Oberste Ebene des Informationsspeichers Michael.hahn@company1.de (primary) Oberste Ebene des...." and so on.

Now the question of the question. WHO Can help me here? Is it a "Bug"? If it is not the right behaviour, which person should know about it?

To replicate you have to: Create an discovery search -> only exchange only -> export with option "one pst file per mailbox"

Thats the very minimal export you could do. and it should import the mailbox just right to the new mailbox. That the folders are matched. But somehow it doesnt...

I tried every possible combination of the powershell commands. But nothing chances the result. Thank you for your time.

Answer 1

@KyleXu-MSFT

read again my last post. IT can perfectly merge with target.

New-MailboxImportRequest -Name "IMPORT0011" -Mailbox "michael.hahn" -SourceRootFolder 'michael.hahn@company1.de (Primary)/Oberste Ebene des Informationsspeichers' -TargetRootFolder '/' -IncludeFolders "/*" -ConflictResolutionOption forcecopy -AzureBlobStorageAccountUri "https://*********.blob.core.windows.net/pstimport/Exchange/michael.hahn.pst" -AzureSharedAccessSignatureToken ""  

That command did it with about 100 mailboxes without any issue!

And as you said "The topology isn't same as the mailbox". Yes absolutely! But shouldn't an export that says "one pst file per mailbox" be expected like something you export from the onprem exchange? I would say yes. Because it shows nowhere that it is not the same like onprem. And on the import side, there is no message or anything about "only with onprem exported pst files".

Thats the "expected" behaviour? I would call it an design fault. Because with the O365 Import job + mapping csv, you have no change to import these pst correctly. Because you cant set the "Sourcerootfolder" value.
When the Import-Job gets an pst like this, accept it and offers you the filter options. But imports it completely wrong. Than there should be an check for this topology and correct it or decline it.

Where can I sent my feedback or open issue at the specific dev team? Is there something on github with that topic? Or is this only "internal" dev team?
I just want to tell somebody some ideas who is actively developing on this, because there is some much you could do better with a little efford.
For example, I can import pst files from my own Azure SAS storage. Why not activivate the "onpremlike" exportcommand with own azure SAS storage subscription?
That would be awesome. Because, when you have only exchange online, you just have the search and export function which creates the previously shown pst file.

What is realy sad and bad on the whole thing:

• NOBODY was able to help me in anyway.
• Everything I wrote was never complete read and understood from a) support and b) here in this thread.

Anyway.... My problem was solved by myself with a lot of freetime involved.
Would be great to get an info., where I could reach one of the specific team.

Answer 2

That's not true. Than please tell me why should the Content Search not be intended for this? What else should be the use of an export like:

"One PST file for each mailbox: Exports one PST file for each user mailbox that contains search results. Any results from the user's archive mailbox are included in the same PST file. This option reproduces the mailbox folder structure from the source mailbox."

As it says it REPRODUCES THE MAILBOX FOLDER STRUCTURE FROM THE SOURCE MAILBOX

If I put these PST-Files into my outlook (Import) it works perfectly when choosing "import into current folder". So the pst files are fine for outlook, why should they not be fine for importing to exchange online?

And as written here: "https://learn.microsoft.com/de-de/microsoft-365/compliance/recover-an-inactive-mailbox?view=o365-worldwide"

If you need to recover data from an inactive mailbox with an auto-expanding archive, use content search to export the data from the mailbox and then import to another mailbox. For instructions, see following topics:

Content search
Export content search results

this clearly shows that it IS intended for such scenarios.

And as this shows:

What does the TargetRootFolder parameter do? As previously explained, you can use the TargetRootFolder parameter to specify a folder in the top of the folder structure (also called the root) in the target mailbox

so I used the command -targetrootfolder "/" which means ROOT and not IPM.

But this also does not give me an clear answer why all the other commands like

[-SourceRootFolder <String>]
[-TargetRootFolder <String>]
[-ExcludeFolders <String[]>]
[-IncludeFolders <String[]>]

do not show any change in the result of the import. With no command I was able to just import it to the mailbox with merging the contents.

On every website I read about "pst export exchange online mailbox with ediscovery" and so on, I found no sign that this process is not working like it should.

But in my case, it clearly does not what it should. I will not use third-party tools if it is possible the export and import pst files. that process should just work, or they should clearly provide some information like "PST-Files exported with this methode are not supported with OFFICE PST Import service and exchange online powershell"

That would make no sense. Because what do you need pst files for? There is no other use as save your mailbox and import it again later. So both processes should just be ready to take the input of the other export.

Answer 3

@KyleXu-MSFT

please look again at the Screenshot I attached in my first post.

Your screenshot does not show any of the issues I am facing. This is an image how it looks from the mailbox view in outlook.

And I was not using "in-place eDiscovery & hold". I used content-search and export. On exchange-online, there is no export-function implemented. So content search is the only way to get pst files out of the database. It should be clear, that the have to be imported someday and any automation would fail because the told issues.BUT in any case.... That the structure of the pst-files is maybe a bit different,
that can't be a reason for the import-job to fail with matching or scanning the pst. You know what I mean?

On the O365 Import Page it showes, that the import-job is looking, whats inside the pst and matches it accordingly.

And here is the point, were it is NOT an expected behaviour. The whole mailbox-rootfolder Structure ist present inside the pst file.

But this content-check does not scan inside the folder which is named after the exporting mailbox. like michael.hahn@company1.de (primary)

So it can'T recognize any wellknownname Folder and match it correctly. It is "out of scope". And that shoulnd be. Or in an other way, it shouldnt be, that the import is recogning anything outside the michael.hahn@company1.de (primary) as an legit mailboxfolder structure and just import it, ignoring any setting which was set before.

Anyway... because I am a person, who can't just "give up" I tried yesterday some import-requests again. Focused on the commands -sourcerootfolder and -targerrootfolder.

First I checked the folder-structure of the pst file with an .net dll and visual studio. so I got an view, how an script or shell is seeing the folders. Which will than give me an direction, how I have to call them in the import call.

So inside the pst it looks like this:

Top of Personal Folders\michael.hahn@company1.de (Primary)\Oberste Ebene des Informationsspeichers\

So that is the mailbox root folder which contains the inbox etc.

Top of Personal Folders\michael.hahn@company1.de (Primary)\Oberste Ebene des Informationsspeichers\Posteingang (german for Inbox)

So with trying some different calls I recognized, that the import call with NEW-Mailboximportrequest on default fetches everything inside "Top of Personal Folders"

There is just one object inside which is michael.hahn@company1.de (Primary)\
Than the process is done and the whole thing gets imported inside the mailbox folder of the target-mailbox with all the other Folders which are not inside the

Oberste Ebene des Informationsspeichers (or translated Top of Information Store)

The import-process just need to get updated to catch also the (Primary) Folders or at least to scan inside this folder to fetch the correct mailboxfolder (with wellknownname).

Do you now understand why I would say, this is NOT it should happen? On the other hand it is faily easy to implement. So why should it not be possible?

After again several ours of trying I found the following command "of magic" which does EXACTLY what it should. It is importing the pst folders and matches them correctly to the Targetmailbox.

New-MailboxImportRequest -Name "IMPORT0011" -Mailbox "d7a1298AZURE-OBJECTIDc47a8b" -SourceRootFolder 'michael.hahn@company1.de (Primary)/Oberste Ebene des Informationsspeichers/Posteingang' -TargetRootFolder "Posteingang" -IncludeFolders "/*" -BadItemLimit 25 -ConflictResolutionOption forcecopy -AzureBlobStorageAccountUri "https://*********.blob.core.windows.net/pstimport/Exchange/michael.hahn.pst" -AzureSharedAccessSignatureToken ""  

And thats it. The import runs successfully without any issues or any other side-effects. Instead the "posteingang" you could choose any folder you like. But the first part is the necessary one. And also you have to use SINGLE quotes for this path. Otherwise it would be fail because the @ sign in the pathname.

So why do two experts tell me, that it is not possible or that it is the expected behaviour? I would say, it should never be "expected behaviour" when the import just imports any folder, even outside the "rootfolder" to an mailbox. I mean most of these folders are not realy made for users, they should in any way not appear inside the normal mailbox-scope.

That whole thing is in my opinion and ISSUE or an BUG or something. But it is far away from an "expected behaviour" in an M365 EXO and E-Discovery structure.

I would be pleased to hear your input. Thank you.

Answer 4

The Content search Export was never intended to be used in such scenarios, and the structure is indeed different from what the Import process expects. To get this to work, you need to import to the actual Root, not the IPM (Top of Information store) root. So I'd say this is the expected behavior here, and you're better off using third-party tools for the migration process.

Answer 5

@Michael Hahn

It is an expected behavior, the structure of pst that export with hold and New-MailboxExportRequest are different:

The "in-place eDiscovery & hold" is used to store email, if email was deleted by mistake, admin could find needed emails for users. It isn't used for import directly.

If you want to migrate mailbox, you can use the new "Cross-tenant mailbox migration" function to migrate mailbox from one tenant to another. Otherwise, you may need to export data and import data from Outlook client.

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.