none
Deleted managed property mapping lingers RRS feed

  • Question

  • Hi all,

    I'm slightly puzzled with the current problem, and I'd really appreciate your help.

    I have some data in a SharePoint list. I've configured the Content SSA crawlers to pick this data up. The crawlers dutifully do, and each field from the list ends up with a ows_{fieldname} counterpart. I then map those counterparts to managed properties with names {fieldname} and all seemed fine.

    Later I noticed that one of the properties was mis-named. So I deleted the managed property, created a new one with a different name and mapped the crawled property to it. Strangely, it was not visible to the index but the old (and now deleted) managed property still was.

    So I thought it must just be the case that the index needed reseting. So I reset the index from CA using Index Reset and cleared the collection named sp using the Powershell cmdlet. However, the problem remained the same. The old (and deleted) managed propertyremains accessible  thorough queries whilst the new field is not accessible.

    Is there some other reset that is necessary? Is there some way to see whats going on in the index more directly?

    Any help on this matter would be much appreciated.

    Emir

    Monday, November 28, 2011 11:19 AM

Answers

  • Indeed, following http://support.microsoft.com/kb/2468431 has solved the problem.

    If bliss doesn't work it needs to be run with the -C -i options.

    Thanks for your help Mikael.

    Emir

    • Marked as answer by Emir123123 Friday, December 2, 2011 11:52 AM
    Friday, December 2, 2011 11:51 AM

All replies

  • Hi Emir,

    Can you open up the file <FASTSearchFolder>\index-profiles\deployment-ready-index-profile.xml and search for an entry with the new and the old managed property names and see what comes up? You can also try to restart the configserver with "nctrl restart configserver" to ensure all config files are loaded properly (or restart FAST entirely).

    Something along the lines of:

    <field ... name="managedpropname"/>
    

    Regards,

    Mikael Svenson 


    Search Enthusiast - SharePoint MVP/WCF4/ASP.Net4
    http://techmikael.blogspot.com/
    Monday, November 28, 2011 9:20 PM
  • Hi Mikael,

    Thank you for your response!

    I've checked the deployment-readin-index.html and the crawled properties are there. Indeed I would expect them to be since I manually created them using the FAST cmdlets. Further, the managed properties corresponding to the crawled properties are there and the two are mapped. I've checked all this using both powershell and CA.

    I've run the nctrl restart configserver command. I've also tried restarting the fastsearchservice service and restarting the computer.

    If the new and correctly mapped property is included I get the error below:

    Property doesn't exist or is used in a manner inconsistent with schema settings.     at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)     at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)     at ECHR.HUDOC.Services.SearchWebService.QueryService.QueryEx(String queryXml)     at ECHR.HUDOC.Services.FAST.FASTQueryService.GetResults(String country, String filterQuery, String sortQuery, Int64 start, Int64 length, String similar)     at System.Runtime.Remoting.Messaging.Message.Dispatch(Object target, Boolean fExecuteInContext)     at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

    Searches work fine if the property is excluded.

    The deleted managed property is still brought back by queries.


    Any ideas?

    Emir

    Wednesday, November 30, 2011 4:14 PM
  • Just to make sure, have you done a full recrawl after you mapped the crawled properties to the managed ones?

    Regards,
    Mikael Svenson 


    Search Enthusiast - SharePoint MVP/WCF4/ASP.Net4
    http://techmikael.blogspot.com/
    Wednesday, November 30, 2011 8:53 PM
  • Hi Mikael,

    Yes several times again without a difference.

    Something I did notice however:

    I found this article http://support.microsoft.com/kb/2468431 and endevoured to follow its instruction.

    Upon running the bliss -C command I receive the following error:

    systemmsg XML Parse error: Value "issue" for attribute separator of field is not among the enumerated set

    If this command or similarly affected equivalent is executed at the beginning or end of crawls, it might equally fail.

    Infact, this hypothesis tallies well with other observations too.

    What do you think?

    Emir

    Friday, December 2, 2011 10:41 AM
  • ok running bliss with -i -C option has successfully updated the index profile.

    It looks to be en-route to resolution...

    Friday, December 2, 2011 11:01 AM
  • Indeed, following http://support.microsoft.com/kb/2468431 has solved the problem.

    If bliss doesn't work it needs to be run with the -C -i options.

    Thanks for your help Mikael.

    Emir

    • Marked as answer by Emir123123 Friday, December 2, 2011 11:52 AM
    Friday, December 2, 2011 11:51 AM
  • Ah... of course :)

    I'm so into SharePoint these days that I forget the old FAST ESP ways ,) Glad you figured it out and thanks for refreshing everyone's memory around index profile inconsistencies.

    -m


    Search Enthusiast - SharePoint MVP/WCF4/ASP.Net4
    http://techmikael.blogspot.com/
    Friday, December 2, 2011 12:00 PM