We had a People type mapping in OOB AccountName MP. We added another string crawled property mapping to AccountName.

We discovered that, this caused miss the Update of current list item in next Continious Crawl cycle. When a new item added, crawl finds and ports to index, but in an update event, crawl does not fetch this update.

When we removed the mapping menitoned above, the issue disappeared and crawl worked without problem.

So came to a point that, having a type check for an MP-CP mapping can be a good idea to be assured of the integrity of the Search Schema.

Thank you

When doing eDiscovery the result for MicroFeed data suffers a few flaws:
- when a query returns a post, the preview for a post is useless for the human reader (the Display-Form of the MicroFeed-list is not equipped for that use)
- when someone puts a hold on a post, he can't preserver the rest of the thread (formulating the extended query needed not possible, as the data model for the MicroFeed-List is not documented)
- when exporting, the export is returned as CSV like for any other list; but as data model of teh Microfeed list is not documented, it#s hard to direct the reader to the right columns to understand a thread
- when exporting list attachments (for the Microfeed list as also in general lists) are not included

Several of the Japanese users (ja) are being detected as Chinese (zh-tw) due to the user properties and they are being indexed incorrectly by the word breaker.
Japanese characters are very unique and often uses Chinese characters.
For example Japanese names often only uses Chinese characters.

When user profile is created in SharePoint Online with user's properties containing a lot of Chinese characters, they are detected as Chinese instead of Japanese.
As a result, their names and other properties are being tokenized in Chinese by the word breaker.

So when the user is searched by the name as a whole (Japanese way), they are not found in the People Search result.

For example, user profile with the following name is created.

User: 小野

Assuming the user profile's properties only contains Chinese characters, the user is detected and indexed as Chinese instead of Japanese.

Actual result: The name is indexed character by character "小" and "野" (Chinese)
Expected result: The name is indexed as a whole "小野" (Japanese)

Few Japanese users have confirmed this issue, and they would like the accuracy of the word breaker process could be improved when detecting Japanese .

The following image contains a use case that I have provided MS support for a design change request.

https://onedrive.live.com/redir?resid=3FD50FD56BA55AA1!214204&authkey=!AOi2bIALcOJNcbk&v=3&ithint=photo%2cjpg

The ultimate issue here is that SharePoint Online search does NOT crawl document level properties. Therefore, DLP cannot use these properties to help protect that document from leaking since DLP is reliant on the search index.

The workaround I have been given is to create a column in the document library where the file is stored; this allows the custom document property to populate the list column in the library upon upload. The challenge with this approach is that this column must be deployed across our entire tenant. This includes all OneDrive sites as well as SharePoint sites. In order to deploy this column to our tenant involves custom development which we try to avoid at all costs as the cost to maintain custom solutions is high.

The next area where this workaround falls down is within Office Groups. Unless an API is available, not sure if one exists or not yet, the Office Groups UI does not allow the user to add columns to the FILES feature within a group.

I can also see a scenario where PDF files are generated from a system and stamped with custom properties. Once these files are distributed within an organization, having the ability for O365 DLP to identify these files based on properties would be a huge win for controlling the data from leaking.