SPSearchManagedProperty: crawled property does not exist (even though it does) #1289
Comments
|
Afternote: These managed properties don't appear in the Central Administration at all, not even "half done" so that the mapping is missing. They are just not created at all. |
|
Hi @rurikon, I have been reviewing the code and it makes sense that the property isn't created. The code checks if all specified crawled properties exist and throw an exception (which stops running the rest of the code) if that is not the case. What happens if you log onto the environment and run the following command: Get-SPEnterpriseSearchMetadataCrawledProperty -Name 'ows_taxId_Business_Keywords' -SearchApplication 'Search Service Application' |
ykuijs
added
bug
|
That command gives nothing. Also this gives nothing, even though there are some built-in properties with the string "Keywords" in them (like ows_q_TEXT_SeoKeywords and SharePoint:BestBetKeywords): If I try the same command with string 'Title', I get two results: As said, when I look at the crawled properties in Central Administration, I can see ows_taxId_Business_Keywords among the 11 different crawled properties that come up with the search 'Keywords'. |
|
Another interesting find: I added the mappings manually (again because we have to move forward with the project), and now DSC doesn't complain and Get-SPEnterpriseSearchMetadataCrawledProperty finds the properties. We have another environment, so I'll try to recreate this there and find the reason why this happened. I'm still leaning towards a bug in SharePoint itself or some of the updates. |
|
Hi @rurikon, in that case it makes sense. If that command can't find the crawled property, the SharePointDsc code also can't find it and therefore is unable to create the managed property. The -contains operator is used for checking if an array contains a value. In this case you have to use -like: Can you try that command and let me know the outcome? In the initial message you also mentioned that you are using SharePoint 2019 RTM. Many Cumulative Updates have been released since that could very well have fixed this issue. Could you please install a recent CU and try the command again? |
|
I noticed my mistake and checked with -like later, but I thought I'd debug a bit further before commenting more :) I did install a later CU, but our two farms behave differently even though they have the exact same CU and are installed with the same settings. I'm trying to figure it out and will update when I know what's going on. In any case, I tried installing August 2020 CU earlier and it was clearly broken, because it just plainly didn't create crawled properties at all, and the same thing with January 2021 CU. Currently I'm testing September 2019 CU, because it fixes some big problems but doesn't create new ones. This is a difficult problem to solve because I can't find any references of other people having the same issues in on-premises, just mentions of this happening in the cloud (and fixes that don't work in on-prem). |
|
Ok, so an update on this. In short: SharePoint continues to behave very weirdly and inconsistently. First of all, I installed the March 2021 CU. It looks like this one doesn't have the same problems as January, or the problems are coming from something other than the CU. On Farm 1:
On Farm 2:
Next I'm going to delete the Search Service and configure everything manually. If that makes a difference, I'll try adding the DSC configuration little by little to see if there's a certain part that breaks things. |
|
The problems in Farm 2 turned out to be a broken solution. I exorcised it and now it works the same way as Farm 1. So apparently Get-SPEnterpriseSearchMetadataCrawledProperty doesn't work quite like it should. The behaviour appears to be the same, whether I use DSC to configure or do it manually. One thing I did notice while doing this is that setting search administrators with SPServiceAppSecurity doesn't work properly either. I have and administrator AD group and while it looks like it's added in the UI, on database level the group doesn't get access to the search databases. When I remove it and add again manually, the database rights are correct. That might explain why I kept having issues where the service pool account's rights would be dropped from one database as described in this blog: https://www.techmikael.com/2014/10/caution-if-you-have-used.html (this happened even though I started creating the service itself with the farm account so it gets the right db owner). This doesn't affect the property issue, but is worth noting if someone else is having the same kind of problems. So, for now I guess I have to add the mappings manually and wait&hope the powershell gets fixed in some future CU? |
|
If I can make a suggestion, maybe this configuration might work better if it created the managed property anyway, even when it can't find the crawled property to map to it. Of course it should return "not in desired state" after that, but that way I could add the managed properties right away and didn't have to wait for a full crawl to finish. It would also work as a workaround for a situation like this, where the crawled property is not found for other reasons. At the moment DSC won't create a managed property at all, if I try to define crawled properties it can't find. So to get around that, I have to first make a configuration without the crawled properties (so the managed properties are created without mappings), then manually add the mappings, then add the mappings to the configuration afterwards (so it can make sure they stay the way they're supposed to be). If the managed property was created even when the crawled property isn't found, I could just write one configuration with the mappings in it, and it would start reporting as "in desired state" as soon as I add the mappings manually (or they are found in a crawl). Of course this is an "architectural decision" and you might have reasons to do it the way it's now, so it's up to you. |
|
I like your idea to create the managed property even when the crawled property cannot be added. If the resource then reports not being in the desired state, it is always a possibility to run Start-DscConfiguration -UseExisting to reapply the config and correct the issue (hoping they can be added by then). I will also have a look into the permissions issue you described in the other post. |
|
Created issue #1311 to track the permissions issue |
Details of the scenario you tried and the problem that is occurring
I'm trying to add managed properties, but SPSearchManagedProperty doesn't seem to accept anything into CrawledProperties. I've checked from Central Administration that the crawled property exists, but DSC says it's missing. I've tried different ways to write the property name, but nothing seems to work.
Here is the configuration I'm using:
SPSearchManagedProperty BusinessKeywords { ServiceAppName = "Search Service Application" Name = "BusinessKeywords" PropertyType = "Text" #Searchable = $true # see issue 1288 Queryable = $true Retrievable = $true HasMultipleValues = $true Refinable = $false Sortable = $false NoWordBreaker = $false IncludeAllCrawledProperties = $false CrawledProperties = @("ows_taxId_Business_Keywords") Ensure = "Present" PsDscRunAsCredential = $SetupAccount DependsOn = "[SPSearchServiceApp]SearchServiceApp" }I tried replacing ows_taxId_Business_Keywords with SharePoint:ows_taxId_Business_Keywords but it didn't work either.
On the node this will report the following:
In Central Administration I see the following info when checking the crawled property:
Property Name: ows_taxId_Business_Keywords
Category: SharePoint
Property Set ID: 158d7563-aeff-4dbf-bf16-4a1445f0366c
There's a possibility this might be a bug in SharePoint 2019 itself, because there have been other issues with search as well, but I'm reporting it anyway in case it's not. The other issues I'm talking about: This is a fresh installation (test environment) and originally I also installed the August CU. I configured most things with DSC, but crawled properties never appeared at all, even when I deleted and recreated the search service manually. I noticed there were reports of similar issues with online Team Sites. I tried all kinds of fixes for months, but nothing worked. I couldn't find anything wrong with the farm, so I reinstalled everything but without the CU, and then crawled properties appeared as they should. However, this didn't help with DSC and it still gives this error, as if the crawled properties don't exist. Another issue with search is what is described here but adding rights did not help in our case. This is an inconvenience, but manageable as long as you don't try to change the rights.
Verbose logs showing the problem
See above.
Suggested solution to the issue
N/A
The DSC configuration that is used to reproduce the issue (as detailed as possible)
See above.
The operating system the target node is running
Windows Server 2019 Standard
SharePoint 2019 "out of the box" with no cumulative updates
Version and build of PowerShell the target node is running
PSVersion 5.1.17763.1490
BuildVersion 10.0.17763.1490
Version of the DSC module that was used
SharePointDSC 4.3.0
The text was updated successfully, but these errors were encountered: