Iw411   migrating content by search from 2010 into 2013 - minified
Upcoming SlideShare
Loading in...5
×
 

Iw411 migrating content by search from 2010 into 2013 - minified

on

  • 442 views

IW411 This is my slide deck from the SharePoint Evolutions 2013 Conference where I looked at content by search in 2010, then migrating and building from scratch in 2013.

IW411 This is my slide deck from the SharePoint Evolutions 2013 Conference where I looked at content by search in 2010, then migrating and building from scratch in 2013.

Statistics

Views

Total Views
442
Views on SlideShare
378
Embed Views
64

Actions

Likes
1
Downloads
3
Comments
0

2 Embeds 64

http://www.myfatblog.co.uk 61
http://feeds.feedburner.com 3

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Some of the key requirements was for separation, Site collections create security boundaries, but they also bring additional challenges.
  • Of all of the challenges that we’re focussing on today, we shall be looking at what we can do to provide roll-ups across site collections.
  • The CQWP (Content By Query Web Part) has some limitations. Queries cannot be run across site collections. Paging is not available out of the box. A little known restriction is from the SPSiteDataQuery limit of 1000 lists. This means that once the CQWP query has touched 1000 lists across the site collection, it will return no results. This means that depending on the configuration of your query, just 100 sub-webs can invalidate your query and the web part will return nothing. (Without any error messages beyond those in the ULS logs.) The CQWP is made scalable through the use of heavy caching, which increases the demand on the WFE. CQWP Does however support the use of [ME] and [TODAY]….
  • The search service application has been designed from the ground up to be scalable. As demand rises across the farm, Query servers and index partitions can be added to scale out. Complex searches can be created. Kryptonite! Can’t use the [ME] token or [TODAY] without custom code. (In 2010) Search crawls
  • To mitigate this in 2010, we would run incrementals as frequently as we could. In 2013, the constant crawler comes to our aid. For the [Me] and [Today] tokens, we had to result to custom code. Less of an issue in 2013.
  • Search scopes to restrict content to what you want to see. Managed properties to display the relevant information. Regular crawls for content freshness. (Content is only as fresh as the last crawl!)
  • By adding fields into the page layout, we improve the edit experience and make tagging easy.
  • Scopes can be very powerful. In our case, we’re only using it to limit results from a single web application. The name you give it here, will be used to target the scope in the web part later on.
  • Some challenges when it comes to troubleshooting. Best approach is to take the raw xml output from search and use a third party tool (Visual Studio, notepad++, SPD) to build the XSLT away from SharePoint.
  • Search Core Results Web Part – Local to the instance of the web part, Horrible editing experience. Site Collection Asset Library – Limited to use within the site collection, Benefits from Versioning. Deployed through feature or SPD From the file system – Can be used throughout the site on any site collection. Deployed through feature or manual copy. A federated location – Can be easily re-used by any site/farm consuming the search service application. Issues with migration.
  • In the new federated location, we give it a name, leave all of the default location options, and then add the XSLT and properties to the Core Results Display Metadata section.
  • We can then picked the newly created federated location in the Location properties tab of the Core Results web part
  • For all of our deployment methods, apart from Federated locations, these have to go in the web part properties. For federated locations, they go in the federated location display properties. Both locations use the same horrible interface, Cut and paste into an XML aware editor! You will save hours of frustration! You must however return them to a single string after editing before pasting back in.
  • Finally we need to add the fixed query that will fire when the page is loaded. Here’ we’re looking for items of the correct content type that match our news stories. contenttype:”LegalCorp News Article Page” Any keyword query that works in the search box can be used here.
  • If it all worked, it looks like this. Note the Featured Sites web part, this is a variation on the same method.
  • Upgrading Service Applications to SharePoint 2013 - http://technet.microsoft.com/en-gb/library/jj839719.aspx Upgrade content databases - http://technet.microsoft.com/en-us/library/cc263299.aspx Personally, There has to be a very good reason to migrate search rather than rebuild, in this migration scenario, we won’t be bringing search across. If scopes are migrated, they cannot be edited. Not convinced that Federated locations migrate fully as I experienced issues with the embedded XSLT.
  • The upgrade in-place will take a variable amount of time depending on the amount of content.
  • After the initial mount process, The basic site is available, but no search results, Requires a crawl to populate the database Styling is also a little weird. Note the prompt for the SharePoint 15 upgrade
  • After the crawl, we now have results, but the images are missing.
  • Full details of the suffixes are listed here http://technet.microsoft.com/en-gb/library/jj613136.aspx
  • With the master page switched, the CSS isn’t working.
  • The finished migrated site after a new SP2013 master page and CSS file is created.
  • The main changes in SharePoint 2013 that change the way we approach our original build are :- Automatic Managed Properties:- These are mapped for us automatically as we touched on during the migration. Results Sources:- These are scopes on Steroids! Display Templates: HTML and Javascript based templates for rendering result items. New Search Webparts – Search Results or Content by Search (In enterprise) Continuous crawl – search freshness becomes less of a problem than in 2010.
  • The basic underlying structure is very similar to the SP2010 version, but now we’re using the full power of SharePoint search and all the new functionality that comes with it.
  • Although the Enterprise web part is a little easier to configure, there is nothing that you can do in one that you can’t do in the other.
  • As with how our solution worked in SP2010, nothing has changed with regards to Site Columns, Content Types, deployment or page layouts!
  • Massive improvement for troubleshooting over XSLT!
  • The use of image renditions in your sites can have a massive impact on the ease of deploying images and ensuring that appropriate images sizes are used and transferred over the network.
  • If a rendition ID isn’t specified, but a width or height is, then SharePoint will try and match the appropriate rendition. E.g. if you specify Width, SharePoint will match the width and return the relevant image. In the case of multiple renditions with the same width, the first rendition found will be returned.
  • Note the entry there about using either the query builder, or another web part. You can use this feature to supply to web parts to the page, from just one query to the search database. For example, in our 2010 site, we had a featured story web part, This could have been our eye catching headline showing the first result, with the summary web-part showing stories 2-5 instead of 1-4
  • Think beyond the singular.. Use webparts in concert to create mashups.

Iw411   migrating content by search from 2010 into 2013 - minified Iw411 migrating content by search from 2010 into 2013 - minified Presentation Transcript

  • Migrating Content by Search from2010 into 2013IW411Paul Hunt
  •  Paul Hunt, MCITP, MCPD Trinity Expert Systems Ltd www.tesl.com paul.hunt@eurodatasystems.com Twitter:@cimares www.myfatblog.co.uk I do woodturning for a hobby!
  • Session Agenda Cross-Site Collection roll-ups in SP2010using Search Core Results Migrating the solution from SP2010 toSP2013 Rebuilding from scratch in SP2013 usingSearch Results/Content by Search
  •  LegalCorp.ComIntroducing ourfictional clientLegalCorp.Com is a fictionalexample of a Global Multi Nationallegal firm.•Practices in 3 main global regions•Americas•EMEA•AsiaPac•Each region represents key legalentities with their own reportingstructures and requirements.
  • Global Challenges The nature of thecompany meant thatthe client wanted touse a site collectionfor each region, witha global site at thetop of the Navigation.
  • Global Challenges This presentedseveral challenges. Consistentnavigation. Content Typesyndication. Client preference toavoid custom code. Roll up of contentfrom each of theregions.
  • What does theclient want toachieve?To roll up news articles from eachof the regions as well as from theGlobal site collection.•The top four stories should bedisplayed in order of creation.•A region icon should be displayedto show where the story is from.•The story title should be displayedalong with a summary of the article.
  • CQWP Limitations CQWP is the usualtool of choice for theroll up of information. Quick and easy toconfigure. Fairly simple tocustomize with xslt. Good for time criticalinformation. CQWP doesn’t workacross sitecollections. CQWP doesn’tprovide paging ootb. CQWP is limited to1000 lists. CQWP increases thedemand on the webservers.
  • Enter our Hero!Search
  • A Search alternative? The search serviceapplication has beendesigned from theground up to bescalable in enterprisesituations. Search results canbe provided frommultiple sitecollections. Search results canbe styled easily usingxslt. Complex searchqueries can beexecuted.
  • Our Kryptonite? Result data is only asfresh as the crawls. [Me] and [Today]tokens are notavailable. (SP2010)
  • Search needs more preparation. In addition to Content Types and Site Columns Search needs:- Search scopes Managed properties Regular crawls
  • Building our Solution inSharePoint 2010
  • Building our Solution Site Columns Content Type Page Layout Managed Properties Scope Search Core ResultsWeb Part XSLT
  • Site Columns Region Sector Primary Sector Article Summary
  • Content Type Name: Legal Corp News Article Page. Inherits from ArticlePage (OOTB). Adds our new sitecolumns.
  • Content Type - Deployment ManualConfiguration Content Type Hub Powershell Solution Package
  • New Page Layout(s) Copied from ArticlePage Adds our new sitecolumns into the editexperience.
  • Managed Properties Before you go any further. Create some content. Tag it properly Full Crawl.
  • Managed Properties Crawled properties are extracted from theindex.
  • Managed Properties These can then be mapped to Managedproperties and used in our web part.
  • Scope Used to limit our results to just our webapplication.
  • Search Core Results Web part Runs our fixed query and shows theresults.
  • XSLT Used to control the rendering output ofour results.
  • XSLT
  • XSLT – Deployment Options In the Search Core Results Web PartProperties In a Site Collectionstyle library On the file system in/_layouts In a federated locationin the service app.
  • XSLT – Deployment Options In the Search Core Results Web PartProperties
  • XSLT – Deployment Options In a Site Collection Style Library Or on the file systemUse the XSL Link in the web partproperties tab to link to the file using arelative path
  • XSLT – Deployment Options In a federated location in the Searchservice application.
  • XSLT – Deployment Options In a federated location in the Searchservice application.
  • XSLT – Deployment Options In a federated location in the Searchservice application.
  • Search Core Results Web Part Configure the managed propertiesto display in results.
  • Search Core Results Web Part Configure Fixed Query
  • Building in 2010 – Key Points Consider the impact tothe search architectureand monitor the farm. Remember to create, tagcontent and crawl it tomake propertiesavailable. Consider deploymentoptions if migration to2013 is likely.
  • PUTTING IT TOGETHER INSHAREPOINT 2010Demonstrating content roll-up using SharePoint 2010 search.
  • Migrating our Solution fromSharePoint 2010 toSharePoint 2013
  • Migration Options There is nosupported in-placeupgrade option. Web applications areupgraded through thecontent databaseattach method. The search serviceapplication can beupgraded through asimilar method. Managed Properties Scopes Federated Locations
  • Migration Process Build new SP2013 farm Restore Search Admin DB (optional) Create Search Service Application Create new Web Application Restore Content Databases Attach content database to webapplication Fix issues!
  • Migration Process
  • Migration Process
  • Migration Process Our site columns arealready configured aspart of the contentdatabase migration,but not the managedproperties.
  • Migration Process SharePoint 2013 nowautomatically addsManaged Propertiesfor Site Columnsdiscovered duringcrawls. A suffix is addedbased on the fieldtype.
  • Migration Process To pick up the newproperties, we firstamend the columnsin our Core Resultsweb part And then the XSLT inthe style library.
  • Migration Process
  • Migration Process
  • Migration Process With a SharePoint 2013 master page
  • Migration Process With a custom Master Page & Css
  • Migration – Key Points Upgraded Scopes & FederatedXSLT can’t be edited postmigration. Managed property names willchange unless re-mapped. Weigh up the benefits of buildingit from scratch in 2013 for theimproved search options.
  • Building our solution fromscratch in SharePoint 2013
  • Flexing the new muscles ofSharePoint Search Automatic ManagedProperties Result Sources Display Templates New Search WebParts Search Results Content by Search(Enterprise CAL only) Continuous Crawl
  • Building our solution Site Columns andContent Types Page Layouts Managed Properties Result Sources Display Templates Image Renditions …..
  • Building our solution …Web Parts Server Standard Cals Search Results WP– More configuration required.– Duplicate trimming requiresthe .webpart file to beamended. Server Enterprise Cals Content by Search WP– Easier to configure– Duplicate trimming off by default– Pre-configured variants
  • Site Columns & Content Types Site Columns Content Types &Deployment Page Layouts Nothings Changed!
  • Managed properties Automaticallymapped from SiteColumns Requires content tobe tagged andcrawled before ithappens!
  • Result Sources Combines 2010federated search andscopes + extras Defined at ServiceApp, Site collectionor Web level. Uses the QueryBuilder to define thesearch.
  • Display Templates Controls therendering of a searchresult item No more XSLT! Html and JavaScriptbased Design managercreates raw JS filefrom the Html
  • Display Templates Each template includes aheader block with keyproperties. These map to the DesignManager properties
  • Display Templates – Tag Rules Understand the tag rules! JavaScript goes inside <!--#_ _#-->
  • Display Templates – Tag Rules Calls to JavaScript variableswithin Html go inside _#= =#_
  • Display Templates – .JS File Generated automatically everytime the .Html is saved.
  • Display Templates – .JS File Troubleshooting is easy withthe IE Developer toolbar!
  • Image Renditions Sizing images made simple Requires Publishing Features Requires Blob Caching Ensures appropriate files sizes
  • Image Renditions
  • Image Renditions Can be used in several ways Picked from the SharePointImage Dialog Or specified in the URL– By ID - ?RenditionID=5– By Size using Height And/Or Width
  • Web Parts – Search Results Server Standard Cals Uses the Querybuilder or anotherwebpart for results.
  • Web Parts – Search Results Select result source in query builder andrefine as needed.
  • Web Parts – Search Results And then choose adisplay template tocontrol the outputrendering.
  • Web Parts – Content By Search Server Enterprise Cals Also uses querybuilder or another webpart for results More options forstyling with Controland Item templates Heavily used incatalog sites
  • Web Parts – Query Priority Both Standard and Enterprise results webparts can be given a query priority for timeswhen search is busy.
  • Building in 2013 – Key Points Familiarise yourself with all ofthe capabilities of 2013 searchbefore deciding on which designroute to take. Think beyond the singular! Dust off those HTML andJavaScript skills.
  • PUTTING IT TOGETHER INSHAREPOINT 2013Demonstrating content roll-up using SharePoint 2013 search.
  • Related Sessions IT102 – SharePointSearch All Up – NeilHodgkinson IT114 – Upgrading,Deploying and Scalingout SharePoint search –Neil Hodgkinson P&M306 – UsingJavascript templates tocustomize the SharePointUI – Chris O’Brien P&M308 – Soup to nuts –How to build a metadata& search driven Intranet –Chris Johnson IW507 & IW508 – Makingthe most of ContentAggregation inSharePoint Pts 1&2 –Christina Wheeler DEV209 – Developersapproach to searchapplications – MatthewMcDermott
  • Questions?
  • Thank you for attending!See you at the conference partytonight!