Posted on:
Categories: Business;Office 365;SharePoint
Description: With the introduction of OneDrive for Business a while back, a few new doors opened up. Users quickly learned that it was even easier now to bring documents in and out of SharePoint and possibly work with documents offline. This sparked a lot of fervor and unfortunately some misconceptions around how to effectively move documents into SharePoint and take advantage of its features.
​With the introduction of OneDrive for Business a while back, a few new doors opened up. Users quickly learned that it was even easier now to bring documents in and out of SharePoint and possibly work with documents offline. This sparked a lot of fervor and unfortunately some misconceptions around how to effectively move documents into SharePoint and take advantage of its features. We have come across a few clients that have come to us and said we just want to move our file shares into SharePoint as-is and start using OneDrive to interact with the files. Some of them said they know their current file structure is a mess but they would tackle the clean up once the documents have been moved into SharePoint. There are a few red flags in this scenario, the core problem is that there is no clear and defined goal for moving their documents into SharePoint. In this situation, simply moving a file share structure, as-is into SharePoint could create many issues and usability problems for end users. What we have seen happen is users end up running into all the limitations/extra steps with using SharePoint without getting exposed to the benefits, ultimately blaming the product. Working with these clients I have established the basic elements that need to be reviewed in order to avoid a digital dumping ground.Plan an Information Architecture Finding and discovering documents is the number one concern for organizations and their end users. File shares are usually created organically, as users see the need for a folder or sub folder they create it put their documents in it and move along. Users typically never check to see if a folder already exists in another location where they can be uploading that document or have they even named the document that makes sense to everybody else. In the end this creates a folder structure that is not standardized or optimized for usability. In the ideal world we would address the following questions Should we be splitting up content/documents along multiple document libraries/sites for usability and security? How can we effectively use metadata and possibly replace folder use? How can we effectively categorize documents so that users can find what they’re looking for quickly and easily?Assign Ownership Letting things grow organically where anyone can do anything isn’t the best way to maintain an effective Information Architecture. Now is the best time to start assigning ownership of content. Have content champions that are responsible for maintaining their own areas and ensuring corporate standards are followed and enforced. Creating an environment where the custodianship of content is shared rather than centralized is a highly effective strategy for creating a sustainable platform.Properly Plan the Migration Now that we have decided we want to avoid the digital dumping ground by doing a little planning, we should also identify the most effective way of migrating the content into SharePoint. Content migration can be a scary thing, especially if you are planning on transforming your content such as recategorizing. If you are planning on introducing metadata to your documents classification, you need a way of tagging your documents during migration. This is the time to explore your options on how to migrate your content, and see if you need a migration tool that will help you tag those documents quickly, minimizing your migration time. Plan for the Limitations Now here comes the source of many problems. Like almost anything in life, SharePoint has its limitations. And if you try to just blindly dump your file share documents and folders into SharePoint, your end users will start running into these limitations. It is important to know these limitations and plan on how to overcome them! Illegal Characters Before you bring any of your files or folders into SharePoint you have to ensure that you avoid using illegal characters for file or folder names. Options for removing these illegal file or folder names can be anywhere from writing scripts or using a third party analyzer tool. As well, some migration tools will help identify and possibly strip out these illegal characters upon migration. For a list of illegal characters for sites, folders, and file names visit https// Name Length Another common scenario we run across is long file names and/or deeply nested folder structures that are migrated as-is into SharePoint. This can mean a document resides at a location such as “ACME Industries\Current Files\Human Resources\2015\Benefits Files\Canadian Benefits\Forms\Insurance Form.docx”. There is a 260 character limit that applies to the entire path of any file that resides within SharePoint. The path contains the site, all folders and sub folders and then the file name itself. With a deep folder structure (as above) and long file name, a lot of our clients have quickly run into this limitation. To get around this, try to flatten out folder hierarchies or avoid folders altogether, instead use metadata. Planning for moving documents properly into SharePoint doesn’t have to be a complicated task; however, taking these steps to ensure that users have the best possible experience and get the most benefit of moving to SharePoint is a key component for end user adoption.

Posted on:
Categories: SharePoint
Description: Explained the use of result sources in SharePoint 2013
​We all know that the SharePoint search engine is very powerful and Search has been a key feature for many years. SharePoint Search provides a fast and user-friendly way to retrieve information or documents. You just enter a keyword into the search box and click 'Search' – it's as easy as that. Almost instantly the results are displayed and can be improved by simply clicking on provided refiners. That provides a very convenient way to search your SharePoint content. Sometimes users require a more streamlined way of finding content that would be less flexible, but provide a faster way to their results. This can be achieved by creating a specific Result Source. In one of my recent projects there has been a requirement to have an additional search box placed on the homepage of a site. This additional search box should retrieve documents of a specific type found in the current site and its sub-sites only. In this blog post I will show you how to create and use a Result Source in SharePoint 2013 to achieve a more targeted search experience. Let's assume there is a site collection that is used to save client related documents like letters, offers, contracts or client-specific presentations. For our example, the site collection will look like this There is a welcome page that provides access to the client workspace and there are three sub-sites for three fictitious clients named 'Client ABC', 'Client DEF' and 'Client XYZ'. To ensure the same "look and feel" and the inclusion of a Presentations library, a custom site template was used to create each of these client sub-sites. Additionally, the Presentations library uses a content type for client-related documents and a managed metadata field called 'Document Type' that allows for easy tagging of documents. A document was added to each library called 'Company Presentation' and was tagged with the document type "Presentation" as shown below I wanted to provide a way to search through all client presentations that are saved to the sub-sites of the client workspaces. In SharePoint 2010 you could use a Search Scope to achieve this. In SharePoint 2013 Search Scopes are deprecated, but can still be used (but not created), so I used a new Result Source for this. SharePoint 2013 already provides 16 preconfigured result sources which are available in all sites, site collections and the web applications that use the Search service application. The main difference between a Search Scope in SharePoint 2010 and a Result Source in SharePoint 2013 is as follows A Search Scope defines a subset in the search index and search results are retrieved by restricting the index. A SharePoint 2013 Result Source is a provider to get search results from. Also, search results can optionally be narrowed to a subset of the results provided by a Result Source. In SharePoint 2010 only two system search scopes are left 'All sites' and 'People'. To be able to create a new Result Source, a managed property needs to be created first. Because I created the 'Document Type' based on a managed metadata saved to the Term Store there will already be a managed property of the same name after an incremental run of the crawler. I create a new Managed Property manually and give it the name 'Document Type'. Obviously it is of type 'Text'. To ensure that this new property can be used, it was also configured to be searchable, queryable and retrievable. This ensures that this new property can be used in search terms and as a search results refiner. Finally, this new managed property needs to be linked to the crawled property. Just to be sure, I did a full crawl now before continuing with creating the new Result Source. Because my client sites are sub-sites to the client workspace, I open the site-collection settings and click on ‘Search Result Sources’ Result Sources can be created for a single site, a site collection or even a Search Service Application. For my example, I'll stick to the site collection. I create a new Result Source and name it 'Presentations', I then select 'Local SharePoint' as the protocol and 'SharePoint Search Results' as a type. Now I scroll down and click on the button 'Launch Query Builder'. One thing I love with SharePoint 2013 are the little embedded helpers, like this one. The following screenshot shows my query configuration which isn't too complex The only thing I need to do here is add a new filter based on the DocumentType property. As property filters leverage the search managed properties, I need to create a managed property called 'DocumentType' first. The search results preview displayed on the right is based on the current query. The preview looks fine and shows all of my demo documents so I click OK to save the current query settings. One of the requirements are that the search results based on this result source should not be displayed in the global Search Center, they should only be displayed on a search results page that is local to the client workspace. To do that, I need to create a site collection specific results page and I continue with creating a new page in the client workspace, which will then become the new local search results page. Once the new page is created, I add a Search Results web part to the page. This web part will be configured to display search results based on the newly created result source, it needs to be configured properly. I open the web part properties and click 'Change query'. In the 'Build Your Query' dialog I only need to change the query's result source to 'Presentations'. As you can see it is very easy to reuse a predefined Result Source. The next step is to add an additional Search Box to the home page of the top level site. This additional search box is used to enable users to search specifically for presentations in the sub-sites of this client workspace. With this approach there will be 2 search boxes, which might be confusing at first glance, but this approach does not have any impact on the existing search environment as the additional search box is utilized by the members of the client workspace only. This is how the home page of the top level site looks like now The additional search box only needs to know where the results page is located. So I just need to change the following setting for the web part to redirect the queries to the local results page that I had just created. Let's assume a sales representative is looking for the slides he or she presented at client XYZ because these slides can be reused and updated to be presented to a new client. All that is needed to achieve this is to enter the original client's name "XYZ" in the local search box and click the search button. This is what the search results look like in my example The expected result is that the local search results page now only shows one single result as there is only one document that is tagged with 'Presentation' that is related to client 'XYZ'. The global search is still working as expected because I did not change any settings here. If the sales representative had used the global search box, the results would be displayed in the global search center like this This is the standard search results page in my demo environment and it shows that there are more presentations (or even sites and pages) that somehow are related to 'XYZ'. In my simple example, I have added another document (basically a presentation with "This is my company" on the first slide) to a sub-site of another site-collection to show the difference to the local results page more clearly. You can also use a custom result source as a new search vertical in the global Search center. You may have noticed the standard result sources of a search center in the above screenshot. The standard result sources used by a global search center are these To add a custom result source to the standard result sources of a global search center you would most likely choose a similar approach like I did. Navigate to the standard Search center and add a new page (just like I have done with the local search results page). You need to change the configuration of the search results web part on the new page just like I did before. Unfortunately this isn't enough to show the custom result source among the standard result sources of a SharePoint Search Center. The result sources in the screenshot shown above are nothing more than links to pages with search results web parts similar to the one I have created before. The link to the newly created page needs to be added to the existing links of the standard pages. To do this, open the site settings of the global Search Center and click on 'Search Settings' under 'Search'. If you scroll down to Search Navigation you should see the standard pages look like this To illustrate the addition of a new page to the global Search Center, I now add a custom search results page (created before and named "Custom") to the existing pages. After I saved the changes and navigated back to the global Search Center, I enter "XYZ" again to the search box and this is what I see now The newly created page (I named it “Custom”) has been added to the standard result source pages of a global Search center just as expected. To get rid of ellipses (“…”) that might appear in your environment, just open the web part properties of the search navigation web part and increase ‘Maximum Links before Overflow’ If you enable 'Turn on the drop down' in the search box web part's properties, the result source pages are listed this way Result Sources introduced to SharePoint 2013 are a powerful new feature because they don't restrict the existing index to display search results. In fact, they add a new provider to SharePoint Search which is a far more powerful approach used to enhance the user's search experience in SharePoint greatly. Although this is just a simple example on how to use Result Sources it shows obvious benefits for the User Experience. To me, as a SharePoint consultant, a user experience that truly reflects the users' needs is as important as the functionality of a SharePoint farm. In this case of using custom result sources, simplicity of finding information on your SharePoint platform can even be achieved without a single line of code – and that's true for Office 365 as well.