Tag Info

Hot answers tagged

5

Try using a KeywordQuery and setting the RankingModeID to "D9BFB1A1-9036-4627-83B2-BBD9983AC8A1" This PowerShell code works for me Add-PSSnapin Microsoft.SharePoint.PowerShell $site = get-spsite "http://localhost" $kq = new-object Microsoft.Office.Server.Search.Query.KeywordQuery($site) $kq.ResultTypes= ...


4

A similar question has been asked before: http://stackoverflow.com/questions/166178/searching-date-meta-tags-in-sharepoint The short answer involves writing your own protocol handler - not for the faint hearted, but it should work nicely.


4

As Vadim mentioned, you cannot create new managed properties in SPO with Refinable option enabled. However, you can map the crawled property (ows_SiteName) to an already created Managed Property in SPO (RefinableString00) as shown in the below image: You can then set an Alias (SiteTitle) to the RefinableString00 property and use it in search just like ...


4

Nothing is stupid here. When you create a custom column in a list do a full crawl and you will see a crawled property available with the name ows_ColumnName. You can't map a column to a Managed Property. You always map Crawled Properties to Managed Properties. So you will have crawled properties from site columns and the YES you can map as many crawled ...


3

I believe you can add a new uerprofile property inside the User Profile Service application with the name as "Org Unit" and configure it to with any specific AD property.Also you can configure it as whether to show this in the profile page, allow it as editable etc..


3

You didn't mention it in your question so just to make sure... Did you perform a Full Crawl of the content source AFTER you mapped the ows_DueDate crawled property to the TaskDueDate managed property? Do you know for sure there is content with a value for the ows_DueDate crawled property? SOLUTION: The problem was due to teh fact that the ...


2

If you click on the Crawled Property link (crawled properties usually begins ows_ as opposed to the Managed properties, which are linked to the crawled property) the page should have a link to some items with that property in use (and set). You may need to ensure the property is included in the index before it'll show up in that page. For me, this works in ...


2

It's there now. I think it was the combination of needing documents in place and a full system crawl, before the crawled properties appeared in the properties store. For others: such properties in SharePoint will appear with the prefix ows_. In fact, there can be a couple thousdand of these, most taken from the default SharePoint infrastructure. Several ...


2

Not sure, it makes any difference but a detailed thread from someone who faced similar issue. The person seemed to have contacted MS Support as well, so you'll see a lot many updates. Here's the article.


2

Found my problem... Instead of a full crawl on the content source, I did an incremental crawl. Silly me... So it worked all along


2

This is how we configure crawled props (before indexing them!): New-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchapp -Name publishdate -Category Web -IsNameEnum $false -VariantType 64 -PropSet "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXX" -IsMappedToContents $true Variant type is 64 - which is the date/time type. Add the ...


2

Html content is usually in the crawled property: Property Set: 11280615-f653-448f-8ed8-2915008789f2 Variant type: 31 Name: html (http://msdn.microsoft.com/en-us/library/ff795815.aspx) You can also add a "Spy" stage to examine what crawled properties are available in the pipeline - and see if you can find the one with the correct content. Or enable ...


2

you can create a calculated column(test) with last updated column, do full crawl and find the crawl property ows_test and map that to your new managed property. and specify the new managed property(text) as column in your sortablecoreresultswebpart. you will get something like this 1 12/5/2012 datetime;#2012-12-05T16:26:10Z you can use ...


2

you can only provide sorting on managed properties. Look for the exact name of the managed property in central administration. I have similar web part and it works for me. Maybe look if the crawled property is correctly assigned to managed property.


2

You need have at least one list item with valid value in this column. Then you need to run full crawl. After the crawl is complete you will be able to see it as *ows_yourcolumnname*


2

You can use PowerShell to create a Crawled property and a managed property. You can use the following code to create and map the properties Param( [string]$crawledProp, [string]$managedProp, [int] $typeManagedProp ) # TypemanagedProp 1 = Text 2 = Integer 3 = Decimal 4 = DateTime 5 = YesNo 6 = Binary 7 = Double $snapin = ...


2

I think you can make a call like this to get the values for owstaxidmetadataalltagsinfo refiner: http:// siteurl /_api/search/query?querytext='*'&refiners='owstaxidmetadataalltagsinfo' You will get some values with this format: L0|#036f7c08a-0176-47e9-9d70-070291ce0e32|Data Warehousing


2

You have to use a pipeline extensibility stage which reads the text based property and writes it back to a new crawled property of type int, which you can map to an int based managed property. I've done the same for date <meta> tags in web pages which are interpreted as text, but you want them as dates. I have a powershell prototype sample here which ...


2

You cannot set the crawl in O365. It is set to do a continuous crawl, and should take ~15 minutes for results to show in search results. However, in times of heavy use, that can increase to hours. This link provides more information: http://www.sharepointnutsandbolts.com/2013/10/waiting-for-search-crawl-in-office-365.html


2

Most of the default managed properties in Search are based upon the text datatype. We noticed the same problem when sorting the search results on 'ArticleStartDateOWSDATE'. The sort order was not correct due to the text datatype. We simply solved it by creating a new managed property 'ArticleStartDateOWSDATE2' with the same settings but with the correct ...


2

The guys have given very thorough answers, to answer your final question about naming. For columns, avoid spaces in List Columns and Site Columns. For Managed Properties do not use dashes. For example do not use "My-Site-Column" as a Managed Property name. The query engine will misinterpret the "-".


2

I just left my client and was unable to resolve this error. The only thing I could do to fix it was basically create a completely new custom display template and recover the hoverpanel and WAC preview window functionality. With my own display template everything worked perfectly fine as it should be.


2

Try isActive=1 this means it equals true. isActive:1 is a contains query.


2

This is not doable with KQL or FQL. You would have to do some post-processing to accomplish this. FQL has an operator called starts-with, but cannot be used with wildcards, only terms or phrases. If you could have another property on the list with AZText which copies the first letter of the value of AZText field, then that would work. Or if you do this in a ...


1

You probably have the wrong crawled property mapped. In my case the site column was named Loan Type and that created the following 4 crawled properties Loan Type Loan_x0020_Type ows_Loan_x0020_Type ows_taxId_Loan_x0020_Type I selected ows_Loan_x0020_Type and did a full crawl and it worked.


1

At the bottom of Manage the search schema in SharePoint Server 2013, it describes the use of these "unused managed properties". It states: The following table provides an overview of the default unused managed properties that you can reuse and rename using an Alias. and continues with a table of managed properties that are shipped OOTB, but that are ...


1

in my opinion, the crawled properties in both section should be the same. You are not correct. FAST Query administration page has two section with access to managed properties and even link to Content Sources (under Crawling). The reason for this is the fact that People Search does not go through FS4SP but instead uses the built-in SharePoint Search. ...


1

You set the scope against the "contentclass" not a property itself. You then restrict the search down to that content type, and then you query on that single field in your search method be it a search webpart or a code behind query. To see how this works look at the "People Scope" which implements this already. So your query then would become: ...


1

I suggest you recreate the "Animals Metadata" column WITHOUT any special characters, and then RENAME it afterwards. This is SharePoint best practice due to how internal representations of names are stored. A space becomes x0020 when encoded and may be further encoded to _x005F_x0020_x005F_ and so forth. You can see how this will develop into a nightmare ...


1

Did you see it happening on SharePoint 2013 RTM? Did you start full crawl? Did you start full crawl immediately after creating new managed property?



Only top voted, non community-wiki answers of a minimum length are eligible