1

I have an on-premise SP2016 site collection where I'm a site collection administrator.

I've created a custom Library, based on a custom Content Type inheriting from the native Document Set. I've bound that content type to my library and removed the default "Document" cotent type.

My custom Content Type contains two custom Site Columns : - My_Collaborator - type : Person - My_Type - type : managed metadata (the term store is the term store of another site collection, which I've shared with this site collection)

I've had no problem adding a document in the document set, and no problem setting a value for all the fields, even the custom fields. I've made sure the document is not extracted and has a major version.

Then I've run a full crawl of the web app (I've access to that too), and made sure it was over.

Now I'm facing this problem : SharePoint doesn't seem to create a Crawled Property for any of my columns. I don't see them when I go to Site Settings --> Search Schema (I'm not confusing with just "Schema").

Why? Is there a setting somehwere that would tell SharePoint to ignore that column?

======

EDIT: There were errors in the Crawl Log about this specific Document Set. I didn't want to leave any potential solution out so I Reset the crawl Index ("Reset Index") and ran a Full Crawl again. This time my document set appears as crawled and the results appear in the search results on the site.

...and yet the Crawled properties based on my columns still don't appear in the Search Schema! I'm going mad.

====

EDIT : I want to stress that any answer about the managed properties is irrelevant. The issue here is that the crawled property does not appear.

|improve this question
  • To this date I still haven't found out why this was not working. I've done exactly the same steps in another site col on another farm, and this time eveything worked as expected (the crwaled property appeared in the Search Schema after deleting the index and doing a full crawl). – jeancallisti May 2 '18 at 16:29
1

In SharePoint 2016 (and SPO) Microsoft changed the way Automatic Managed Properties work. They still create the "ows_q_" property but they do not create or map the "Friendly Named" property. You can still do this manually at the Site, Site Collection, or SSA level. Implicit Managed Properties in SharePoint and SharePoint Online

|improve this answer
  • I don't care about the managed property, regardlessly of its name. It's the crawled property not being created that infuriates me. – jeancallisti Apr 13 '18 at 13:53
  • I am pointing out that there are two crawled properties created, and the name does matter because they have different uses. Sounds like a bug. I would look at your CU level and determine if that is the cause. – Matthew McDermott Apr 14 '18 at 12:35
  • What's the CU level? – jeancallisti Apr 17 '18 at 14:59
  • Do you mean how do you determine your CU level in SP2016? To get your Farm build level (which may or may not be your actual CU level) you can run $(Get-SPFarm).BuildVersion and compare it here: sharepointupdates.com/Patches to determine your full CU level in SP2016 you can use the cmdlet Get-SPProductInformation from here: github.com/Nauplius/SharePointProductInformation – Matthew McDermott Apr 17 '18 at 15:16
  • No, I didn't know that CU meant "Cumulative Update". I have 16.0.4588.1000 (which does not appear in the list, closest one being 16.0.4588.1001) – jeancallisti Apr 17 '18 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.