File Modified date misalignment in SharePoint, Explorer View and file shares/drives

04/09/2012

Most of you have been using for ages now the Explorer View of a Document Library. It’s indeed one of the most controversial features SharePoint (sometimes painful for IT Pros) offered since early days but is arguably one of those feature that seduced the “normal” and non-IT users thanks to the easiness of move/copy drag and drop.

During a recent scenario we discovered a misalignment between a file’s “Modified SharePoint metadata field and the actual Date Modifiedof the file as displayed in the Explorer View (if one uses the Explorer View of a Document Library or if the Document Library is mapped as a network drive on the users computer – very common scenario for users) or if one checks the date of the file properties in Office applications (e,g Word, Excel, etc)

The complete scenario is as follows: the “Modified” column in SharePoint has been basically overwritten during a copy/move operation performed using the Document Library Explorer View and now reflects the “Modified” date in which the moving operation was done instead of the last modification date of the file itself.

Below the picture displays the Modified date as it appears in SharePoint (2/08/2012) which is indeed the date where the file was moved from the source to this Document Library:

Below the picture displays the Modified date as it appears if we use the Explorer View on the same Document Library (with the original date when the file was truly modified (27/7/2012):

When you upload a document to a document library SharePoint will use the last modified date as the date which the upload was done while the Explorer view (Windows) will display the modified date stored as property of the file itself!

This behavior can also be explained from another angle: “Modified” date in SharePoint is actually the Content Type modification date while “Modified” date in Windows (classical file shares or drives) is the date of the file itself.

Well, in our case this behavior creates big problems given the fact that many users continue to use the Explorer View in order to access and find their work files in their department or team site (most of them simply remember that the file they look for it was modified at a certain date in time so they will look for that file rather sorting on the modified date than on performing a search).

We looked than for a way of mapping these inner file properties reported above, carrying the last modification date of the file, onto a site column to be shown in a Document Library View. We know that this approach is very useful for search purposes: in Shared Services Administration -> Search Administration -> Metadata Property Mapping we can map the properties Basic:14(Date and Time), Basic:16(Date and Time), ows_Modified(Date and Time) onto a new property labelled, for instance, LastModifiedTime (see pic below).

Nevertheless, this mapping seems to be useful for search purposes only and unfortunately Microsoft confirmed that there is no out-of-the-box configuration for our purpose.

It seems that the only out-of-the-box solution would be to use Backup and Restore which will then preserve the original last modified dates…or custom development of course (event handlers, etc)


Harshness of the Enterprise Search Solutions

13/04/2012

Une très intéressante analyse de Stephen E Arnold suite aux grands acquisitions du marché en fin de l’année dernière (HP a acheté Autonomy et Oracle a acheté Endeca) que je vous invite tous à lire.

Main conclusions :

  • Whatever the search solution, the users never embraced trully one or truly satisfied..still don’t find what they look for.
  • Cost control is really inexistent. Open end costs for enterprise search solutions. Search and semantics are getting always more complicated and more costly…not what a manager or a user wishes.
  • Social behavior: it is easier to ask someone for information than search, browse, discover, or interpret jazzy charts to get it.”
  • Good thing is that innovation (in accessing and retrieving information) will continue: « innovation will continue because search, content processing, and the hot sectors like semantics run into the mercurial characteristics of language” 🙂

Read the entire analysis:

http://arnoldit.com/wordpress/2011/10/23/enterprise-search-silliness/

Thanks Stephen E Arnold!

If you have an Enteprise Architecture or a Portal project I fully advise you to read the RealStory group reports on Enterprise Architecture solutions: http://www.realstorygroup.com/Reports/Search/ and Portal Solutions:  http://www.realstorygroup.com/Reports/Portals/

They will cost you something like 2-3 days of consultance but they are really comprehensive. Very useful for SWOT, TCO or aquisition analysis.


Creating Search-Based Solutions with SharePoint 2010 (MDV03) – my notes

30/09/2010

SharePoint Connections 2010, Den Haag, 28 September 2010

Session: Creating Search-Based Solutions with SharePoint 2010 (MDV03)

Speaker: SCOT HILLIER

  • Great slide on the Search Architecture (get the slides)
  • Content source->iFilters->.NET Assembly Connector-> Index Engine
    • The big news is that the indexer uses a .NET assembly connector to access exernal data (a new .NET assembly connector can be easily written by a developer)
    • There is now an architecture support for search federation
    • Relevancy:
      • Ranking vs Sorting
      • Authoritative Pages is a primary way to affect ranking
      • In SharePoint 2010 we can create a specific Custom Ranking Model
      • Using Custom Ranking Models
        • Define Weights & Normalizations through an XML file specifying:
          • Query independent elements (e.g. all documents ending with .docx be pushed at the top of search results)
          • Query dependent elements (e.g. all queries beginning with ‘a’)
  • Define Managed properties and explicitly activate it for use.
  • Install the ranking Model
  • Update the Core Results Web part to use this Ranking model (you have to define the ranking model ID in this web part…if no ID specified, the one of SharePoint by default).
  • SharePoint 2010 has 5 ranking models defined. The one by default is general for all searches and the rest of the models apply especially to people search. The IDs of these ranking models are not visible through the UI – you have to export them and check the GUIDs in XML.
  • When SharePoint query does not contain any text but only a managed property, the Search skips the ranking of search results  (the ranking model is not used) and the search results are simply displayed but not sorted using the ranking model. (e.g. put in the search box “Rating>0”, given that AverageRating is a manged property) As soon as a text is included in the query, the ranking model is taken into consideration before displaying the search results (e.g. search for “a* Rating>0”)
  • In SharePoint 2010 we can inherit the CoreResultsWebPart class!!! And build our own custom CoreResultsWebPart class
  • In order to help user you might wish to use separate pages by scope (tabs on top of the search box)
  • INTERESTING use case: a unique place on your SharePoint site where the user can check all tasks he’s assigned to. Instead of building a CAML complicated web part/solution, you could use the search engine and query for all “AssignedTo” properties across your farm (check code in demo).  You can use FullTextQuery Class to process SQL queries. (e.g. show all the latest documents on the portal)
  • Keyword query syntax examples:
    • Lastname:A
    • AverageRating>0
    • Training+isDocument:1
    • Client AND Server
  • A demo of using the keyword query syntax : AZIndex of employees in the directory
  • .NET Assembly connectors
    • It is the WAY we allow the index engine access an external system
    • The fact that anyone can write a .NET assembly connector (choose Business Data Connectivity Model in Visual Studio) gives the opportunity to index practically any existing external system
    • It’s the same ‘piece’ used by the BCS (Business Connectivity Services) to search and access data from external systems
    • Security: Search results trimming vs query time trimming
  • Search queries stay entirely compatible with OpenSearch standard