Corey Roth [MVP] : SharePoint, Office 365 Grid

SharePoint 2013 Autocomplete textboxes using the term store and CSOM

CoreyRoth — Tue, 30 Apr 2013 15:30:00 GMT

I wanted to create an autocomplete textbox in a SharePoint app recently by using terms from the term store. Since retrieving items from the term store can be a bit involved I wanted to show you the steps involved. This solution make use of jQuery UI Autocomplete. The code loads the terms from the term store and then sets the source. This implementation is really only ideal for a small amount of terms, but it’s enough to get you started.

For this example, I am going to use a simple set of terms using state names in the United States. My terms are included in a group named Classification and a Term Set named States. Here is what my term store looks like.

In this example, we’re going to build our code inside a Client Web Part. Take a look at that post if you are not familiar with the process yet. We then need to add a heap of JavaScript references. Some of these are included already, but specifically we need to load SP.Taxonomy.js. We also need to include init.js as I mentioned in an earlier blog post.

<script type="text/javascript" src="../Scripts/jquery-1.7.1.min.js"></script>
<script type="text/javascript" src="/_layouts/15/MicrosoftAjax.js"></script>
<script type="text/javascript" src="/_layouts/15/init.js"></script>
<script type="text/javascript" src="/_layouts/15/sp.runtime.js"></script>
<script type="text/javascript" src="/_layouts/15/sp.js"></script>
<script type="text/javascript" src="/_layouts/15/sp.taxonomy.js"></script>

My web part is called AutocompleteWebPart.aspx so I am going to add a JavaScript file for my code called AutocompleteWebPart.js. We also need to include a reference to jQuery UI You’ll need to download this and include it in your project or pull it from a CDN.

<script type="text/javascript" src="../Scripts/AutocompleteWebPart.js"></script>
<script type="text/javascript" src="../Scripts/jquery-ui-1.9.1.custom.min.js"></script>

Lastly to use jQuery UI, you need to include it’s CSS file in the Content folder of your project.

<link rel="Stylesheet" type="text/css" href="../Content/jquery-ui-1.8.22.custom.css" />

Now, I am just going to add a textbox to the body of our page.

<body>
    <div>
        <input id="autocompleteTextBox" type="text" />
    </div>
</body>

The process for querying terms is involved. You first need to get a reference to the Taxonomy Session, followed by the Group, the Term Set, and finally you can iterate the terms. There are a lot of good examples out there but many of them take short cuts by using GUIDs for values for things like the group and term set. This works but is absolutely useless when you are writing proper code that can be deployed to any environment. You need to be able to reference these items by name, but unfortunately the API makes accessing anything in the term store by name difficult. It’s not impossible though, it just requires extra code and iteration. Let’s walk through our JavaScript example below with absolutely no hard-coded GUIDs.

We’ll start by adding some global variables. We’ll populate these as we go.

var context;
 
var session;
var termStore;
var groups;
var termSets;
var termsArray = [];

We’ll start in a document ready function. We use the standard code to get a reference to the current context. We’ll need this to create a new TaxonomySession object. We then session.GetDefaultSiteCollectionTermStore() to get the default term store. From there, we need to context.load on the session and termStore objects. We then use a typical executeQueryAsync method to execute our query. The onTaxonomySession method will handle success and we’ll use a shared onTaxonomyFailed method to handle any failures.

$(document).ready(
    function () {
        context = new SP.ClientContext.get_current();
 
        session = SP.Taxonomy.TaxonomySession.getTaxonomySession(context);
        termStore = session.getDefaultSiteCollectionTermStore();
        context.load(session);
        context.load(termStore);
        context.executeQueryAsync(onTaxonomySession, onTaxonomyFailed);
    });

Just like with the managed API, you must configure your Managed Metadata Service Application Client appropriately in order for the default term store call to work. Click on the Managed Metadata Service Connection and then click Properties. Now, make sure the checkbox next to This service application is the default storage location for column specific term sets is checked. Once, you have made this change your code should work.

The onTaxonomySession method then retrieves a list of groups. We have to retrieve all groups because there isn’t a method to just retrieve one by name. Although there is a method to retrieve a group by id. Since we don’t want to hard code any GUIDs though. We have to retrieve all groups and iterate them to find the one we want. A successful query will call onGroupsLoaded.

function onTaxonomySession() {
    groups = termStore.get_groups();
    context.load(groups);
    context.executeQueryAsync(onGroupsLoaded, onTaxonomyFailed);
}

In this method we have a list of the groups so we need to iterate through them and find the one we want. In this case, Classification. The code isn’t ideal but it works. We start by getting an enumerator with getEnumerator(). We then use this enumerator to examine the groups. In our loop, we use get_current() to get currentGroup. We then use get_name() to compare against the one we want. When a match is found, we call another method getTermSets and pass the term set.

function onGroupsLoaded() {
    // iterate termStores
    var groupEnumerator = groups.getEnumerator();
 
    while (groupEnumerator.moveNext()) {
        var currentGroup = groupEnumerator.get_current();
        if (currentGroup.get_name() == 'Classification')
            getTermSets(currentGroup);
    }
}

In the getTermSets method, we call get_termSets.

function getTermSets(currentGroup) {
    termSets = currentGroup.get_termSets();
    context.load(termSets);
    context.executeQueryAsync(onTermSetsLoaded, onTaxonomyFailed);
}

The onTermSetLoaded method will then iterate through the term sets returned and compare by name in the same way. In this case, we are looking for the term set named States. When the match is found, we call getTerms().

function onTermSetsLoaded() {
    var termSetEnumerator = termSets.getEnumerator();
 
    while (termSetEnumerator.moveNext()) {
        var currentTermSet = termSetEnumerator.get_current();
        var termSetName = currentTermSet.get_name();
        if (termSetName == 'States')
            getTerms(currentTermSet);
    }
}

This is now the last call we need to make. This retrieves all of the terms for the term set. Unfortunately, we have to get all of them (as far as I know) which is why I don’t recommend this with large term sets.

function getTerms(termSet) {
    terms = termSet.get_terms();
    context.load(terms);
    context.executeQueryAsync(onTermsLoaded, onTaxonomyFailed);
}

The onTermsLoaded method will iterate through the terms and add them to an array that the jQuery UI autocomplete method will accept. There you have it all of the code to get items from a term set without a hard coded GUID. It’s a lot of code, but not too bad once you get used to it.

Lastly, we’ll get a reference to our textbox and use the .autocomplete() method passing in the value of our array.

function onTermsLoaded() {
    var termsEnumerator = terms.getEnumerator();
 
    while (termsEnumerator.moveNext()) {
        var currentTerm = termsEnumerator.get_current();
        termsArray.push(currentTerm.get_name());
    }
 
    $("#autocompleteTextBox").autocomplete({ source: termsArray });
}

At this point, we are done, but we do need to implement our failure method.

function onTaxonomyFailed(sender, args) {
    alert('Taxonomy Error:' + args.get_message());
}

If you are using this code in an app, the last thing you need to do is set the Taxonomy permission to Read in the AppManifest.xml file. This will let us query the term store.

At this point, we can test it. Deploy your app and add the app part to a page.

So, a little code involved here but the results are great. You can configure the jQuery autocomplete plugin in a variety of ways too. This code could probably be optimized some so if you have improvements, let me know.

How to: Query SharePoint 2013 using REST and JavaScript

CoreyRoth — Tue, 09 Apr 2013 19:15:40 GMT

I have a session coming up at SharePoint Summit Toronto this year about the many different ways you can query search. Whenever I am working on a new talk, it is customary for me to write blog posts about my examples so here it is. :) I first learned how to query SharePoint 2013 search with the new REST API and JavaScript from looking at examples from @ScotHillier on MSDN. However, the last time I tried the example, I noticed an issue which I equate to most likely a change between beta and RTM. This post shows you my version of how to query search using the REST API and JavaScript.

For this post, I am using the RTM Office Developer tools (which I have a post coming out on soon). I am going to use a SharePoint-hosted app for my example but you could also use this in a web part with farm solution as well. When it comes to apps, you need to be sure and request permission to access search. Do this by editing your AppManifest.xml and clicking on the permissions tab. Select Search and then select QueryAsUserIgnoreAppPrincipal. If you forget this step, you won’t get an error, your queries will simply just return zero results.

For my example, I am just going to add my code to the default.aspx page in the app. I simply add a textbox, a button, and a div to hold the results. The user will type in his or her query, click the button, and then see search results. You could put this in a Client Web Part if you wanted.

<div>
    <label for="searchTextBox">Search: </label>
    <input id="searchTextBox" type="text" />
    <input id="searchButton" type="button" value="Search" />
</div>
 
<div id="resultsDiv">
</div>

Now, we need to add the necessary code to App.js. I start by removing the example code that retrieves the user information. I instead, add a click handler to my searchButton to execute the search query. If you remember from my previous post on REST, we assemble a URL by appending /api/search/query to a SharePoint host URL. For example.

http://server/_api/search/query

However, in an app, we have to request the URL to the App. One way to do this is by query string using the SPAppWebUrl parameter. SharePoint passes this parameter to your app start page automatically. We can request it with a line line this. Remember getQueryStringParameter() is a helper method that we have gotten from some of the SharePoint examples. I’ll include it in the full code listing at the bottom of this post.

var

spAppWebUrl = decodeURIComponent(getQueryStringParameter('SPAppWebUrl'));

To pass the user’s query to SharePoint, we need to include the querytext parameter on the REST URL. Be sure to enclose the value in single quotes. Again more details in my previous post.

http://server/_api/search/query?querytext=’SharePoint’

Now, we need to create a click handler for the search button, build the URL, and then execute the query.

"#searchButton").click(function () {

});

Inside the click handler, assemble the URL, using the concatenation of the spAppWebUrl, /api/search/query, and the querytext parameter. The value of querytext will be retrieved from the textbox we added earlier.

var queryUrl = spAppWebUrl + "/_api/search/query?querytext='" + $("#searchTextBox").val() + "'";

Now, we just execute the query with $.ajax(). Pass the queryUrl in the url parameter. This example uses the GET method but if you have a lot of parameters, you may consider using POST instead. Lastly, this part is key to get this example to work. The accept header must have value of "application/json; odata=verbose". The odata=verbose part is not in the MSDN example. If you leave it out, you will receive an error. The last parameters are the methods that will handle the success and failure of the AJAX call. Here’s what the whole method looks like.

$("#searchButton").click(function () {
    var queryUrl = spAppWebUrl + "/_api/search/query?querytext='" + $("#searchTextBox").val() + "'";
 
    $.ajax({ url: queryUrl, method: "GET", headers: { "Accept": "application/json; odata=verbose" }, success: onQuerySuccess, error: onQueryError });
});

Now, you need to write code to handle the success. The results come back in JSON format, but unfortunately, they are buried in a hugely nested structure. Each individual result can be found in data.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results. Your best bet is to assign this a variable and then use a template or manually parse it. In my example, I am just going to use $.each to iterate through the results using brute force. The individual columns of each search result can be found in this.Cells.results.Value. Ok, that’s confusing I am sure, so let’s look at the code and then step through it. I’m just writing out a simple table by appending HTML tags to a div.

function onQuerySuccess(data) {
    var results = data.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results;
 
    $("#resultsDiv").append('<table>');
 
    $.each(results, function () {
        $("#resultsDiv").append('<tr>');
        $.each(this.Cells.results, function () {
            $("#resultsDiv").append('<td>' + this.Value + '</td>');
        });
        $("#resultsDiv").append('</tr>');
    });
 
    $("#resultsDiv").append('</table>');
}

Effectively, I have two nested loops. One to iterate through each result and one for each managed property (column) in the results. When you get inside the Cell, this.Value will show the value of the result while this.Key will contain the name of the managed property.

The last thing to implement is the code to handle errors. It’s relatively simple and just writes error.StatusText to the div.

function onQueryError(error) {
    $("#resultsDiv").append(error.statusText)
}

When I run my app, here is what it looks like.

Executing a query in the app, gives us results but they aren’t pretty. You can pretty them up yourself. :) It also doesn’t include anything to print out the managed property names on the table. You could get the names by looking at each cell of the first result and using this.Value.

You can see, it’s really pretty easy to get started. You can further refine your REST query to request specific fields, sort orders, and more. I’ll probably write a follow-up post in the future to include some of those details. Here’s the whole source code for my example that you can work with.

var context = SP.ClientContext.get_current();
 
// This code runs when the DOM is ready and creates a context object which is needed to use the SharePoint object model
$(document).ready(function () {
 
    var spAppWebUrl = decodeURIComponent(getQueryStringParameter('SPAppWebUrl'));
 
    $("#searchButton").click(function () {
        var queryUrl = spAppWebUrl + "/_api/search/query?querytext='" + $("#searchTextBox").val() + "'";
 
        $.ajax({ url: queryUrl, method: "GET", headers: { "Accept": "application/json; odata=verbose" }, success: onQuerySuccess, error: onQueryError });
    });
 
});
 
function onQuerySuccess(data) {
    var results = data.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results;
 
    $("#resultsDiv").append('<table>');
 
    $.each(results, function () {
        $("#resultsDiv").append('<tr>');
        $.each(this.Cells.results, function () {
            $("#resultsDiv").append('<td>' + this.Value + '</td>');
        });
        $("#resultsDiv").append('</tr>');
    });
 
    $("#resultsDiv").append('</table>');
}
 
function onQueryError(error) {
    $("#resultsDiv").append(error.statusText)
}
 
//function to get a parameter value by a specific key
function getQueryStringParameter(urlParameterKey) {
    var params = document.URL.split('?')[1].split('&');
    var strParams = '';
    for (var i = 0; i < params.length; i = i + 1) {
        var singleParam = params[i].split('=');
        if (singleParam[0] == urlParameterKey)
            return decodeURIComponent(singleParam[1]);
    }
}

That’s all there is to it. Hopefully, you find this example useful. Thanks.

The complete Visual Studio for this code snipped has also been uploaded to MSDN Code Samples.

Importing Search Configurations with SharePoint Apps

CoreyRoth — Wed, 03 Apr 2013 16:21:44 GMT

The Office Developer Tools team snuck a new feature into the RTM version of the tools for Visual Studio 2012. This new feature allows you to deploy apps and actually alter the search schema on the host web. That’s right. You can deploy an app and it will directly change the search configuration on the host. They just released documentation on it a while back, but as usual, I wanted to share my experiences. That and I know you all like screenshots.

What does this feature actually do? Well let’s back up a bit. If you remember back from my post, Search is Everywhere, I mentioned the we now had the ability to export and import search settings. This works at the SSA, site collection, and site level and allows you to move everything from result sources to managed properties from one environment to another. This is big as it lets you finally promote search settings between environments and maintain a true SDLC when it comes to search. Why do we care about search configuration with apps? Well this allows the developer to package up search settings in Visual Studio 2012 and then move them to production without having to do manual steps or use PowerShell. This also means you could include search settings in an app that you would put in the Office Store. It certainly opens up possibilities.

To test this out, go to your source site collection and customize your search settings. In my example, I created a custom result source and some managed properties on our source site. In my example, I actually did this on an on-premises installation of SharePoint 2013.

This particular result source does nothing exciting. It simply limits the search to documents, but it serves as a good example. I’ve also created a managed property mapped to the Author crawled property. You may already know about this part, but I am showing it for a reason.

Now, I am going to export my search settings of my site collection, by going to Site Settings –> Search –> Configuration Export.

At this point, I could manually import the search settings using Configuration Import on another site collection. However, we want to do this from an app. Let’s get started in Visual Studio 2012. Start by creating a new SharePoint-hosted app. Once it is created, add an item to the project and choose Search Configuration.

The next step will ask for the path to your configuration XML file that you exported.

At this point the process is done. It will show you an XML editor with the contents of your search configuration. According to the MSDN documentation, you then need to edit it and set the DeployToParent element to true.

We then need to grant permissions to access the Site Collection. To do this, open AppManifest.xml and then click on Permissions. On this tab, add a scope of Site Collection and set the value to Full Control.

At this point, we are are ready to deploy. In my example, I am taking my search configuration and deploying it to an Office 365 SharePoint Online tenant. When the app deployment completes, you’ll be prompted if you want to trust the app. Trust it and then you should see your app start page.

At this point, you are just going to see you default app start page. There is nothing visible in the application. Go to the Developer Site (or the site collection you deployed to) and go to the Site Settings. Then look at the Result Sources. If everything worked correctly, you should now see your new result source there.

It was successfully deployed. Now what about the managed property? Unfortunately, it is no where to be found. If you go back to Visual Studio and look at your XML, you’ll notice that your managed property definition is no where to be found there either. If you check the source file before you imported it though, you’ll see the definition. After I noticed this particular behavior, I reached out on Twitter and @chakkaradeep reached out to me and told me that managed properties aren’t supported in this deployment model. That made me kind of sad because that’s what I want to deploy the most. I’m sure there is a technical reason though that he’ll explain to me sometime though. You can still deploy managed properties via Configuration Import though which is still a great added feature of SharePoint 2013.

You might be curious if the result source is removed when you uninstall the app. It turns out that the changes are indeed removed when you uninstall.

Aside from the managed properties not being available, this is still a pretty cool feature and it has me thinking about some new things I can do that I didn’t think were possible before. I’m pretty excited to work with it more.

Configuring and using IRM with Office 365 and SharePoint Online

CoreyRoth — Thu, 28 Mar 2013 21:34:16 GMT

I’ve always founds IRM quite fascinating and the nice thing about Office 365 is that it is really easy to configure and use. There are a few steps involved, but I managed to figure them out without having to go read a heap of documentation. I thought I would share my experience here today so you know what’s possible. This assumes you are on a new Office 365 tenant or one that has been upgraded already (not that any of mine have been. :) ). I know this is only available in certain plans and I need to double-check which ones, but I haven’t had a chance yet. If you set up a trial from MicrosoftOfficeDemos.com, you can definitely try it with that account.

To configure IRM, it requires you turn it on in two places: in the Office 365 Portal and in SharePoint Online tenant administration. Let’s start by going to the Office 365 Portal. You can get there by clicking on Admin –> Office 365 at the top. Then click on Service Settings –> Rights Management. Rights Management is disabled by default, so you need to activate it.

On this screen simply click Manage and you will be taken to the Windows Azure Directory Rights Management site (notice the URL changes). From here, you can start the activation process.

Click the Activate button and you’ll be taken to a screen to confirm.

Click the Activate button again and the process gets started.

Now, you need to go your SharePoint tenant administration to activate it there. Click on Admin –> SharePoint and then Settings. In the middle of the page, look for the Information Rights Management (IRM) section and check Use the IRM service specified in your configuration. Then click Refresh IRM Settings. Now, it takes a few minutes for your activation to take effect in the Office 365 Portal so if you click on this too early, you are likely to see the following error.

Error: RMS Online is configured for this tenant but is turned off, please turn on in Office 365 to enable.

Keep trying and after a few minutes, it should activate. Be sure and click Save when you are done.

At this point, you can actually try things out inside office. I’m working off of the demo sites that I mentioned earlier. Now, one thing to point out is that Office uses whatever account you are signed in with to determine which Rights Management Server to connect to. Therefore, if you are using a test Office 365 account, you need to actually, log into Office with that account. Simply click on your name in the top right and click Switch Account. If you don’t do this, it may time out or try to connect to another RMS server like the one at your company.

To try things out, open up a document on your SharePoint server, click File and then click Protect Document and then Restrict Access. The first time you choose this, there is an option to connect to rights management services. Once it connects, you’ll see options on protecting the document. We’re going to go with Restricted Access.

On the next screen, you will be prompted to assign who can view the document or edit the document. In my example, I am going to grant read permission to Sara Davis. I simply typed in her full Office 365 Id. This means she will be able to open the document and view it, but cannot save or print it.

If you click on More Options, you’ll get a window where you can set even more granular permissions such as expiring the document, allowing printing, as well as an E-mail address that gets used to request additional permissions.

Once we are finished, save the document back to SharePoint. Now, when Sara opens the document, she is going to get a different experience. To test using the document with Sara, I have to sign in to SharePoint with her account. I also have to open Office and sign out with Garth and sign in with Sara’s account. Here’s what it looks like.

Office informs me that access is restricted and if I click View Permission, it will show me what I am allowed to do. Notice I can only view the document. If I try to access the document with a user who does not have access granted through IRM, Office tells me I can’t open the document like this.

When a document is protected with IRM, Office Web Apps will be unable to show a preview of the document’s contents. Here’s what it looks like when that happens.

I really like how easy it is to get started with IRM in Office 365. If you have an interest in this feature, check it out today. It’s definitely much easier to get started with it here than it is on-premises.

Microsoft Partner Benefits: Rocking your SharePoint Online demos

CoreyRoth — Fri, 15 Mar 2013 15:51:11 GMT

If you haven’t heard, Microsoft released a new site recently that allows you to create a new Office 365 tenant that is pre-populated with users, content, and social data. It even comes with demo scripts that you can use to walk users through the new features of SharePoint Online. What’s the catch? Your Windows Live ID must be affiliated with a Microsoft Partner and you need to have plenty of time to wait for it to provision. It typically takes between 8 and 36 hours for the provisioning process to complete. Tenants are created in trial mode and you have 30 days that you can use it for free. After that, you can either pay for licenses or simply request a new tenant. This isn’t necessarily a bad thing, because the sample social data expires after 14 days. If you want to demonstrate social, it’s really just easier to get a new tenant.

Even if you work for a partner and a lot of you out there do, I found that a lot of people aren’t affiliated with their company’s partner Id. So if you click on the Microsoft Partner link and it gives you an error, you need to affiliate yourself with your company’s partnership. I’ve given a few colleagues this link to associate themselves and it appears to have worked for them. Let me know if you have an issue with it.

When you are ready to create a new tenant, go to the Create Demo page. This page is a bit confusing because all of the options are disabled. Just click Create Your Demo to proceed.

On this page, you specify your region, tenant name, and E-mail address. You’ll get an E-mail when the process completes with the URL and login information.

After you fill in your information, click Create My Account and start waiting. This is an excellent time to review some of the demo scripts out there. Click the Resources link at the top and you’ll see demo scripts broken up by product. This is also an excellent time to go ahead and stop reading this article and get your tenant provisioning. You can come back and read more once you get it started. :)

When the process completes, you will receive an e-mail with the login and password. Click on that link to begin exploring. However, for most of the demos they recommend a demo user, Garth Fort. The login for this user will be garthf@tenantname.onmicrosoft.com. The password should be the same for all accounts pass@word1. Keep that in mind. You may want to change the default passwords of your accounts. If you look at the users section, you will see a number of user accounts have been created for you. It even includes things like conference rooms. These users have pictures and completed user profiles and even social data which we’ll see later.

I’m going to focus on SharePoint content, so click on the Admin link at the top and choose SharePoint. When you go to the SharePoint Online administration tenant, you’ll see that it creates a number of site collections.

Although it’s fairly obvious. Here’s a quick summary of what’s in the site collections.

Root (/) – Demo landing page. Links to the various site assets and demo scripts for SharePoint
/Search – Search Center
/sites/BICenter – Demos using Power View and Visio Services
/sites/Communities – fully populated community sites with discussion boards
/sites/Contoso – main Intranet site
/sites/ContosoBeta – no content
/sites/eDiscovery – discovery center
/sites/KnowledgeCenter – knowledge center with custom branding

What I like about these demos is that there is a lot of examples of what SharePoint can do and a lot of the features are really highlighted. I’ll take you through some of the pages so you have an idea of what you can expect. When you go to the root of your tenant, you’ll see a landing page with links to the demo home page, assets, and scripts.

A good starting place is the Demo Home Page.

Now is a great time to start exploring the site. What I like is a lot of the sites demonstrate out-of-the-box features. Take a look at the Engineering Department site. They have an example of showing reports with Power View using Excel Services.

If we look at the Sales and Marketing site, it has some nice examples of KPIs, the PowerPoint viewer as well as documents that have been rated.

If you’re looking to tell a story about BI, click on the Report Dashboard link on the left. There is a good example of a Power View sheet with filters and maps.

One of my favorite sections of the demo is the Communities section. It’s a great example of using social and shows off the gamification concepts quite well.

Going to one of the communities, you’ll see active discussion boards with top contributors.

You can view individual discussions to show how users interact with each other.

I think the social aspects are some of the best things to demo. If you click on the Newsfeed link, you’ll find quite a bit of activity. Just keep in mind this information will expire after two weeks so it’s good to keep a fresh tenant when you’re doing a demo.

In the screenshot above, you’ll see posts from users that Garth is following as well as various things the user has posted or followed. That video can be watched directly from the newsfeed too.

Clicking on one of the tags such as #CSAT will show you all of the posts that have used that particular hash tag.

There are good examples of the user being mentioned by other people as well.

Search demos extremely well with SharePoint Online because Office Web Apps is included and running.

When doing a demonstration, you can show the hover panel on search results with the preview of the document. I especially like showing users how you can jump directly to a specific section of a document. You’ll also notice how you can filter by Tags or Content Type.

The MOD demos also provide a working eDiscovery center, but I don’t think there is a link to it so you’ll have to type the URL in yourself. This is a great way to show examples of how SharePoint can place holds on SharePoint and Exchange content. If you look at one of the open cases (i.e.: CT77A11), you can define a discovery set. You’ll need to login as the admin account to do this.

If you look at the sources, you can see I have added a few Exchange mailboxes as well as a SharePoint site. Clicking on the Preview Results button will show you content from both Exchange and SharePoint based on the filters you provided.

Everything comes back in these results, so remember your mailbox can always be seen by someone. :)

The BI Center is pretty slick as well. Take a look at the Custom Satisfaction Dashboard. This is a great example of combining graphs with Power View and adding a social aspect that people can comment on.

The last thing I will point out is the Knowledge Center. Here is a great example of how they really changed the way content looks in SharePoint.

Of course, there is plenty of content out there for you to explore. If you can’t sell someone on the value of SharePoint with these demos, you’re doing something wrong. :) Get out there and try it out today (or tomorrow when it finishes provisioning). Here’s the link again for you to get started.

MicrosoftOfficeDemos.com

Workaround for freezes in Client Web Part Editor in Visual Studio 2012

CoreyRoth — Thu, 10 Jan 2013 15:55:36 GMT

If you have tried to do any work with SharePoint 2013 Client Web Parts with the Office Developer Tools Preview 2 in Visual Studio 2012, you know it’s an exercise in frustration. It literally locks up every three or four lines of code you try to type. When it does this, it will freeze for ten seconds or more. This occurs when you are editing the page associated with the web part. It’s a total productivity killer.

It finally bugged me enough that I started looking for a solution. I was pretty close to switching to notepad. Luckily, I found a quick work-around by launching a different text editor. To launch another editor, right click on your web part page in the Solution Explorer and choose Open With…

Choose Source Code (Text) Editor.

This editor is similar to the Web Form Editor but it won’t lock up. You will lose IntelliSense and AutoComplete. However, I’d gladly close my own div tag to not have the editor lock up every ten seconds. The HTML is still color coded at least, but the JavaScript is not. Your JavaScript should be in a separate file anyways though. :) If you have been experiencing this issue, I hope this helps.

How to: Sort search results by query string with the ResultScriptWebPart in SharePoint 2013

CoreyRoth — Wed, 09 Jan 2013 20:21:09 GMT

By now you may have noticed that Search has changed quite a bit in SharePoint 2013. The ResultScriptWebPart powers most of the magic behind the Search Center. It replaces the CoreResultsWebPart that we have been using since SharePoint 2007. I expected many things in it to operate the same, but this web part really has been rewritten from the ground up and that’s a good thing. One new feature (of many) it brings us is the ability to sort search results. You can specify a sort order in the query or by enabling it in the web part properties. This allows the user to pick from a list of properties. I’ll cover it in the future because it deserves a quick post. However, for you developers out there, I know that some of you will want to write some code that passes a sort order. This post explains how to do it.

Before we begin, you have to know what you can sort of. There are a lot of options out-of-the-box such as Author and Write (Modified Date) or you can use your own property. Whatever you choose, you need to check the managed properties page and make sure it has the Sortable option set to Yes - active. You do this from the Search Schema page on your site collection or Search Service Application.

Since SharePoint 2007, we have been able to pass a query using KQL using the “k” parameter to the results.aspx of your search center. We can still do this in SharePoint 2013. To add a sort order though, we do things a little differently. Using a new query string parameter called Default, we can pass in a number of properties including sort order. The format is quite a bit different though as it uses a JSON notation. To start, I am going to issue a query with out k parameter using this new JSON notation. Let’s do a search for our sales documents. To do this, I include my search center URL (/search/pages/results.aspx) and append #Default= to it followed by the JSON object with a name value pair {"k":"Sales"}. When I assemble to entire string, it looks something like this.

http://server/search/Pages/results.aspx#Default={"k":"Sales"}

Now we want to add sorting. To do that, we use the “o” parameter. It takes a collection of JSON objects. The parameter p represents the managed property to sort by and the value d is the sort direction specified as a 0 or 1. A value of 0 represents ascending and a value of 1 represents descending. For example to sort by modified date descending, we use the Write managed property. The string would look like this:

"o":[{"d":1,"p":"Write"}]

When we add it to our query string from above it looks like this.

http://server/search/Pages/results.aspx#Default={"k":"Sales","o":[{"d":1,"p":"Write"}]}

This shows us the newest documents. In SharePoint 2013, they moved the modified date to the InfoCard so you actually have to hover over a search result to see the date. To show the oldest documents, you would just specify d:'”0” instead.

As another example, we could also sort by Author.

http://server/search/Pages/results.aspx#Default={"k":"Sales","o":[{"d":0,"p":"Author"}]}

I’ve included a bigger screenshot where you can see the name of the first author in the list on the InfoCard.

We can also combine them to have multiple sort orders, but I have had mixed results with that so far. Here’s what the query string would an example look like though.

http://server/search/Pages/results.aspx#Default={"k":"Sales","o":[{"d":0,"p":"Write"},{"d":1,"p":"Author"}]}

I’m pretty excited about sorting functionality in the search center. Users have been wanting it for quite a long time and only a select few ever had it (those with FAST Search for SharePoint). If you are writing search solutions, be sure and check my post about sorting with the REST API. This technique works with both SharePoint 2013 on-premises as well as SharePoint Online Preview. All of the screenshots came from Office 365.

Seven reasons why I prefer developing SharePoint apps with SharePoint Online

CoreyRoth — Thu, 20 Dec 2012 21:53:26 GMT

If you know me then you know I’ve been doing a lot of work with apps lately (SP2 – link, twitter). I started developing primarily with an on-premises virtual machine running SharePoint 2013, but I have recently switched to using SharePoint Online (Office 365) more.

Free Office 365 Developer Site – The first benefit is that you can sign up for a free Office 365 Developer Site. This is a great way to get your feet wet with SharePoint 2013 without having to worry about installation and configuration. You can create a developer site collection and publish your apps here and get started very quickly. Especially if you use the “Napa” Office 365 Development Tools.
Less setup – setting up SharePoint 2013 has a fair amount of complexity, but nothing that most of you can’t handle. However, setting up apps is even harder as you have to set up a wildcard DNS entry to do it correctly. Office 365 takes care of all of this for you. Your subdomains are automatically provisioned for your apps, all you have to do is publish and you’re good to go. If you plan on using provider hosted or auto-hosted apps, SharePoint Online is easier as well.
You don’t have to set up Workflow – Setting up workflow is hard. I messed it up on my last attempt on my SharePoint 2013 virtual machine and I haven’t bothered to go back and fix it. When I needed to build an app that used workflow, I started publishing to SharePoint Online. It just works here and you don’t have to worry about installing Workflow manager and all of the related items.
Seller Dashboard team tests here – I discovered this when one of my apps was failed a while back and the issue only occurred on my SharePoint Online tenant. The nice thing about apps is that once everything is configured they work in both on-premises and in the cloud (depending on the type of course).
You don’t need SharePoint 2013 installed – You can develop SharePoint apps without having SharePoint 2013 installed. This means you can do the development directly from your host OS.
Test Licensing App – If you are doing license validation (and you should), the Test Licensing App helps you test this much easier. It allows you to generate a test license for free, paid, and trial apps. I believe this app is self-hosted (or maybe auto-hosted) which means it is much easier to get running with SharePoint Online. When you do install it, be sure and wait several minutes before trying it because it takes some time before it will work. If you don’t use this app, you have to create XML files to represent the test license and install them with PowerShell.
Testing with latency – some of your users are likely to use SharePoint Online. When running in the cloud, things have more latency than on-premises as you know. As a result, some JavaScript that you write may perform greatly on-premises but not so well in the cloud. This is a great way to test for this and see if you need to make any adjustments or add caching.

I have also found that publishing to SharePoint Online really doesn’t seem to take any more time that it does locally (most of the time). The biggest drawback here is that you can’t debug workflows. That may be a deal breaker at some point, but hasn’t been a problem for me yet. You can debug your JavaScript using Visual Studio just fine though.

Follow me on twitter: @coreyroth.

How to: Use PowerShell with SharePoint Online Preview

CoreyRoth — Thu, 29 Nov 2012 13:59:00 GMT

I recently spoke about PowerShell at SharePoint Conference 2012 (SPC195). It turns out PowerShell support slipped into SharePoint Online Preview without a lot of people noticing. In my session at SPC12, I walked users through a lot of common scenarios of using PowerShell with SPO that I wanted to share with you. This post will show you how to get connected to your SharePoint Online tenant and how to do work with sites. In a follow-up post, I’ll show you how to work with users and groups. Keep in mind this only work with SharePoint Online Preview right now. When your existing V14 tenants get upgraded to V15, you will be able to use it then.

To get started, you need to install the SharePoint Online Management Shell. Since this is based on PowerShell 3.0, you need to have that installed. If you have Windows 8 or you are running this on a machine with SharePoint 2013 already, you’re ready to go. However, if you are running Windows 7, you’ll need to install Windows Management Framework 3.0. After you have installed it, simply launch SharePoint Online Management Shell from the start menu. You shouldn’t need to run it as Administrator.

Connecting to SharePoint Online

Before you connect to SharePoint Online, you’ll need to have the username and password for an account with global administrator permissions. You’ll also need to know your tenant admin URL (i.e.: https://mytenant-admin.sharepoint.com). When connecting to SharePoint Online, don’t forget to reference all URLs securely using https. If you try and use http, you will get an error.

To connect to SharePoint Online, use the Connect-SPOService command. It takes the URL to your tenant admin and a username. When you connect, you’ll be prompted for your password.

Connect-SPOService –Url https://mytenant-admin.sharepoint.com –Credential admin@mytenant.onmicrosoft.com

If you connect successfully, you will be returned to the command prompt without error. To see what commands are available, we can use Get-Command and pass it the module Microsoft.Online.SharePoint.PowerShell.dll. You can get the full list on TechNet.

Get-Command –Module Microsoft.Online.SharePoint.PowerShell

Getting Site Collections

To work with Site Collections, use Get-SPOSite (TechNet). It can return a single site with the –Identity parameter or it can filter a list of them with the –Filter parameter. The Filter parameter does server side filtering and can be used with the case sensitive operators (-like, –notlike, –eq, and –ne). You can also run it without any parameters to return all site collections.

Get-SPOSite

This doesn’t return the data in the greatest format though. It would be nice to see the full URL and when thinking about upgrades it would nice to see the CompatibilityLevel (either 14 or 15). We can do this by piping the output to Format-Table (ft) and specifying the desired fields.

Get-SPOSite | ft Url, CompatibilityLevel

You’ll notice that the CompatibilityLevel came back as 0 here. This is because, Get-SPOSite uses CSOM under the hood and it does not request all values by default. To get this data, you need to add the –Detailed parameter.

Get-SPOSite –Detailed | ft Url, CompatibilityLevel

The syntax of the server side filtering can be a bit tricky. The key thing to remember is that the operators are case sensitive so they must be lower-case. In the example, below I do a server-side filter looking for any site with the word “Contoso” in the URL. Put the expression you are searching for in braces.

Get-SPOSite –Filter {Url -like “*term*} | Ft Url

One thing you may have noticed is that there are not any commands to create subsites. Currently only site collections are supported.

Creating Site Collections

Site Collections can be created using the New-SPOSite (TechNet) cmdlet. This cmdlet takes a heap of parameters. Note that you still have to use the preset managed paths available to you in SharePoint Online.

-Url – full URL of the site collection (don’t forget to use https)
-Owner – full user name of site owner (i.e.: admin@mytenant.onmicrosoft.com)
-StorageQuota – in MB
-ResourceQuota – number of resources to allocate
-Template (Optional) – i.e.: STS#0 – Use Get-SPOWebTemplate to view a list of available templates
-Title (Optional) – name of site collection
-NoWait – instructs PowerShell not to wait until the cmdlet is finished

New-SPOSite -Url https://mytenant.sharepoint.com/sites/sitename -Owner "admin@mytenant.onmicrosoft.com" -StorageQuota "500" -NoWait -ResourceQuota "500" -Template "STS#0" -Title "Site Title"

As mentioned above, you can run Get-SPOWebTemplate to return a list of available site templates.

Get-SPOWebTemplate

Deleting Site Collections

To delete a site collection simply, use Remove-SPOSite (TechNet) and pass it the URL in the Identity parameter. It can also optionally take the –NoWait parameter was well.

Remove-SPOSite –Identity https://mytenant.sharepoint.com/sites/sitename –NoWait

Restoring Site Collections

Deleted site collections get moved to the site collection recycle bin. To restore a site collection that you have deleted, use Restore-SPODeletedSite (TechNet). It takes the same parameters as Remove-SPOSite.

Restore-SPODeletedSite –Identity https://mytenant.sharepoint.com/sites/sitename –NoWait

Upgrading Site Collections

SharePoint Online also has the concept of deferred site collection upgrades. This means you can upgrade the site collections one-by-one or in batch using PowerShell. To run the Site Collection health check first, use Test-SPOSite (TechNet) and pass it the URL in the identity parameter. Once you are ready to upgrade use Upgrade-SPOSite (TechNet). Be sure and pass the –V2VUpgrade parameter or it won’t upgrade it.

Test-SPOSite -Identity http://mytenant.sharepoint.com/sites/sitename

Upgrade-SPOSite -Identity http://mytenant.sharepoint.com/sites/sitename -V2VUpgrade

Unfortunately, I don’t have a tenant that can be upgraded yet, so I can’t provide a screenshot of this procedure.

Hopefully, you found these PowerShell cmdlets useful. I think they will help a lot when it comes to working with SharePoint Online. In the next post, we’ll cover how to work with users and groups.

Licensing Changes for Extranets with SharePoint 2013 and SharePoint Online

CoreyRoth — Wed, 28 Nov 2012 19:40:07 GMT

In the past, licensing for Extranets proved to be quite confusing. Many people including myself weren’t always sure what to recommend. I found this useful information in the slide deck for SPC181 and I thought it was worth sharing since I know not everyone got to attend SPC. Ultimately in SharePoint 2010, you had two choices:

Purchase a SharePoint Server license plus one CAL for every user (whether internal or external)
Purchase a SharePoint for Internet Sites license (FIS)

In SharePoint 2013, this has radically changed. The FIS license is now gone and you just use a regular SharePoint Server license for Internet (or Extranet sites). This simplifies things quite a bit. For extranets, you still need a CAL for each internal user. The good news is that Client Access Licenses (CALs) are not longer required for external users. If you have an extranet on SharePoint today this might mean you can save some money. Now what does external user mean? Let me quote it exactly so that there is no confusion.

External users means users that are not either your or your affiliates’ employees, or your or your affiliates’ onsite contractors or onsite agents.

My interpretation of this now is that this basically refers to people outside of your company (but not your contractors). This would be people like vendors and partners. I guess technically, according to the statement, a contractor who never comes on-site is considered external. This statement is a bit fuzzy, but I think the gray area is not as big as it was before.

For those running your extranets in the cloud, we also got quite a bit of good news here as well for Office 365 / SharePoint Online. In the first release of SPO, external users were kind of in a gray area. Basically, it stated that Microsoft will give you 50 external users for free but they reserve the right to charge you for any additional users you have in the future. This has now been solidified. If you are on a SharePoint Online P plan, you get 500 external users free. For the E plans (or SharePoint Online Plan 1 and 2), you get up to 10,000 external users. That should last most of you for a while which I think makes SharePoint Online a very viable Extranet solution.

I think these are some pretty exciting changes for Extranets for both on-premises and with Office 365. What do you think?

How to: Build a SharePoint-hosted Client Web Part in SharePoint 2013

CoreyRoth — Thu, 02 Aug 2012 01:33:49 GMT

NOTE: This post is build with Visual Studio 2012 RC and Preview 1 of the Office Developer Tools. See this post for an update with Preview 2 of the Office Developer Tools and the RTM version of SharePoint 2013.

I am extremely interested in the new SharePoint 2013 App model so I have been doing a lot with them lately. The latest thing I was trying was building a SharePoint-hosted Client Web Part. I have found that there is not a lot of information out there yet on how to use these so I wanted to share some of the things I ran into. This post on MSDN is good to help you get started with the setup of your app. Hopefully this info will help you get started. This post assumes you have installed Visual Studio 2012 RC as well as the SharePoint development tools.

After you open Visual Studio 2012 RC, create a new SharePoint app by choosing Office / SharePoint –> Apps –> App for SharePoint 2013.

You’ll then be prompted for the type of app as well as a name and deployment location. For the deployment location, you need to specify the URL to a site created with the Development Site template. I created a new site collection for this. I am not sure if it is required or not but I am fairly certain it is.

At this point, you’ll have a new SharePoint-hosted App project. Now, we just need to add the pieces that we need. However, first you need to understand a little bit about the ClientWebPart. This new type of web part is essentially two pieces: an elements.xml file and an .aspx page. The elements.xml file performs many of the same functions as a .webpart file, but it has different parameters. It’s main purpose is to specify the path to a .aspx page which it then loads in an IFRAME. Since it is an IFRAME, this page can actually be hosted anywhere: locally, on a remote web server, or in Azure. However, hosting it locally inside SharePoint is by far the simplest.

We’ll create the Client Web Part using the New Item menu:

When the Client Web Part is created, you’ll get an XML file that looks like this.

You can update the Client Web Part title, description, and size here. Note, that end users can’t change the size of the Client Web part once it’s deployed so set the value correctly here. Note the Content element. We need to update this value to the location of the associated page we are about to create. We need to specify the URL to the page associated with our ClientWebPart. To do this we make use of the ~appWebUrl token and then just specify the relative path Pages/HelloWorldClientWebPart.aspx. Here is what the entire XML looks like.

<?xml version="1.0" encoding="utf-8"?>

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ClientWebPart Name="HelloWorldClientWebPart" Title="HelloWorldClientWebPart" Description="This is my awesome HelloWorldClientWebPart." DefaultWidth="300" DefaultHeight="200">
 
    <!-- Content element identifies the location of the page that will render inside the client web part
         Properties are referenced on the query string using the pattern _propertyName_
         Example: Src="~appWebUrl/Pages/ClientWebPart1.aspx?Property1=_property1_" -->
    <Content Type="html" Src="~appWebUrl/Pages/HelloWorldClientWebPart.aspx" />
 
    <!-- Define properties in the Properties element
           Remember to put Property Name on the Src attribute of the Content element above
    <Properties>
      <Property Name="property1" Type="string" WebBrowsable="true" WebDisplayName="First Property" WebDescription="Description 1" WebCategory="Custom Properties" DefaultValue="String Property" RequiresDesignerPermission="true" />
    </Properties>   -->
 
  </ClientWebPart>
</Elements>

You can pass properties from the the user enters from ClientWebPart itself to the page here, but we’ll cover that in another post.

Now, we need to create the page that will be loaded in the IFRAME by the Client Web Part. For simplicity, I go with the same name as the Client Web part.

The default page looks like this.

It’s this part where I couldn’t find any details on how to proceed. You might be wondering if you need to do something to this page before it will work in a Client Web Part. The answer is “yes”. If you do try to deploy it as is, you’ll get the following error when trying to use the Client Web Part.

This content cannot be displayed in a frame.

Luckily, Saurabh Bhatia came through for me in the forums and helped me out. You need to include the AllowFraming tag in your page to allow it to render in an IFRAME. Everything else in the page needs to go with the exception of the reference to the WebPartPages tag. If you leave references to the master page or content place holders, you’ll receive a heap of JavaScript errors. Here’s what my complete page looks like.

<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<WebPartPages:AllowFraming ID="AllowFraming1" runat="server" />
<div>Hello World Client Web Part!</div>

At this point, we are ready to deploy. You can do so by pressing F5 or choosing Build –> Deploy. This will package your app and after a moment, you’ll see your app listed.

This is a Client Web Part so you don’t need to click on your App here. Instead, go to the Home Page and then edit it. Pick a place on the page and then click on Insert in the ribbon. You’ll notice this looks a bit different, choose App Part and you’ll see your new Client Web Part listed.

You might be wondering what the difference between this and Web Parts are. Not much really. If you click Web Part and then choose Apps and you’ll see the same list.

If all goes well, your Client Web Part should now be visible on the page. You may be prompted for authentication again when it loads. You can adjust your browser security settings to avoid this.

At this point, you have a working Client Web Part. You can then make use of the Client Object Model or the new REST API to interact with SharePoint. I hope this helps you get started with building some apps. Try it out and see what you can do.

UPDATE: To use the JavaScript Client Object Model with an App Part, see this post.

Slides and Video from my Lync and Learn Session on SharePoint Online Development

CoreyRoth — Mon, 30 Jul 2012 20:36:15 GMT

Thanks to everyone who attended my Office 365 Lync and Learn session last week. I enjoyed the opportunity to show everyone how they can use Visual Studio 2012 RC to get started with SharePoint Online development. I’ve attached a link to my slides as well as the video on YouTube. Also special thanks to Josh Topal for setting it all up and getting people to attend.

I’ve already had a few people reach out for questions. If you have any others, feel free to contact me.

Follow me on twitter: @coreyroth

How to: Take your SharePoint Online Preview Public Web Site Online

CoreyRoth — Wed, 18 Jul 2012 22:32:23 GMT

Maybe, this was more obvious to other people but it took me a while to figure out. When you first provision your Office 365 Preview Enterprise account, a public site collection is created. It took me a while to find it at first because I was used to finding my public site collection at -web.sharepoint.com">http://<name>-web.sharepoint.com. However, that didn’t work. I went back to the site collections page and noticed that the public site collection is now at -public.sharepoint.com">http://<name>-public.sharepoint.com.

I tried that URL by clicking on it through the Site Collections page using http as opposed to https and what did I get?

Now, I thought that was odd because I don’t remember things working that way. I finally posted something and got a response from Microsoft. The public web site collection run in offline mode by default and you must take it online for it to work. To do that you must visit your URL using https as in -public.sharepoint.com">https://<name>-public.sharepoint.com. Once, you do that, you will be prompted for authentication and you still see the starter site that looks like this.

You’ll notice in the top there is a link that says WEBSITE OFFLINE. Click on that and it will tell you about taking your site online.

When you click MAKE WEBSITE ONLINE, your site will get a confirmation screen.

Click Make online and your site will be exposed via http and anonymous users will be able to access the site.

Note, the new Blog link. People have been wanting that feature for a while with SPO sites. I think we’ll see a lot of blog sites moving to SPO now. You’ll also notice a search box right in the master page. No longer do you need to use hacks to get it to work. If you can’t figure out how to get your public web site going with SharePoint Online Preview, hopefully these steps have helped.

Search is Everywhere! What you need to know about Search in SharePoint 2013 Preview

CoreyRoth — Wed, 18 Jul 2012 02:37:45 GMT

As I start writing this post, I know this is going to be one of those posts that covers so much that it is going to hard to cover it all. The point of this post is to give you a high level idea of everything new and changed in Search with SharePoint 2013 Preview. Search is everywhere in SharePoint now so it is important to understand how it has changed. For example, take a look at this document library utilizing the power of Search.

Aside from cool stuff like drag and drop, document libraries directly leverage the search engine to allow users to filter documents easily. Gone are the days of relying on CAML for simple document library searches. You’ll find out why later in this post on why you can rely on search for those uses as well.

In SharePoint 2013 Preview, Search was essentially rewritten from the ground up. You’ll see familiar concepts like managed properties as well as how FAST Search for SharePoint morphed into this new product. The concept of FAST Search for SharePoint servers is gone. The components from FS4SP have made their way directly into SharePoint and we don’t need separate dedicated servers for it (necessarily). If you’re familiar with FAST ESP, you will see some familiar components from there too. Don’t worry, we aren’t starting over from scratch, but you will see some exciting new things that make search such a powerful feature of SharePoint.

Today’s post will provide a high level of many of the new concepts in search. It will serve as a springboard for a series of detailed articles about the individual components of Search that I will post in the coming weeks. We’ll cover Search in the following areas: topology, crawling, querying, user interface, API, and SharePoint Online.

Topology

The underlying search topology has changed quite a bit. However, most of it is based upon concepts you may have seen before from FAST Search for SharePoint. Components can be scaled out to multiple servers as needed. These changes can be done through the Search Service Application or through PowerShell. When making changes to the topology, you don’t change the active topology, you clone the original, make changes, and then change the active topology. This section is pretty technical so feel free to skip it if you are only interested in the cool stuff like querying and the user interface. :)

Components

The first thing to cover is how the topology changed. Many components got new (but similar) names and they correspond to FAST Search for SharePoint components. The Search components are hosted on your SharePoint application servers using a Search Service Application. Components can be scaled to multiple servers for performance and redundancy. The components that make up search are:

Crawl Component

The crawl component crawls the actual data from a variety of sources such as SharePoint, File Shares, User Profiles, and Databases using BCS.

Content Processing Component

This component processes crawled items and feeds them to the index component. This is where document parsing occurs as well as IFilters exist. A generic IFIilter will cover most of your needs. It also is responsible for language detection and entity extraction (both of which are features from FS4SP). It also produces the phonetic name variations for people search.

Index Component

If you are familiar with FAST Search for SharePoint, the index component will look pretty similar. The Index Component is used in both feeding and query processes. It takes items from the content processing component and writes them to the index. It also receives queries from the query processing component and returns result sets. The Index architecture is based off the rows and columns concepts in FS4SP. Index Replicas (rows) provide a level of redundancy with groups of servers. Index Partitions (columns) allow you to split the index between servers.

Analytics Component

The Analytics Component analyzes crawled items and how users interact with Search Results. It truly is a part of what makes search “learn” and provide better search results to the user.

Query Processing Component

This component performs linguistic processing at query time such as work breaking, stemming, spell checking, and the thesaurus. When the query comes in, it completes it’s processing and passes it to the query component.

Search Administration Component

The administration component stores the various information about search that you configure through the user interface in the Search Service Application. It also manages topology changes.

Search Processes

The search processes look a bit different than what you may be used to. The Host Controller is a Windows service that manages various processes called NodeRunners. When you first install SharePoint 2013 Preview and you wonder where all your memory is, you’ll see multiple NodeRunner.exe processes at the top of the list. Each NodeRunner.exe hosts one of the various components above. Looking at the task manager, it is not obvious which process is running which component. There is a PowerShell script that will tell you, that I will post in the future. Lastly, MSSearch.exe is the Windows Service that hosts the crawl component.

Crawling

The configuration of crawling looks similar but there are lots of changes. Many of the configuration changes you make aren’t limited to the Search Service Application any more. Changes can be made at the site collection and some can even be made at the site.

Content Sources

Content Sources are configured in much the same way, but there are some changes. The newest feature here is the concept of Continuous Crawling. This crawls your content source continuously (every 15 minutes by default). However, there is some magic that occurs now and new items can appear in the index within seconds. This is something users have always wanted and I am really excited about it. It also means that when the full crawl is executing, you can see changes to the index while it is still running.

Result Sources

Results Sources effectively combine Scopes and Federated Locations into one interface. However, they added a ton of new features in how you can build the queries that make up the result source. In a new instance, quite a few result sources are available out-of-the-box such as Local SharePoint Results, Popular, and Items Matching a Content Type. Here is what it looks like.

Whereas SharePoint 2010, only had protocols for Local Search and OpenSearch 1.1, SharePoint 2013 Preview (as well as SharePoint Online Preview), support for Remote SharePoint servers and Exchange has been added. Since SharePoint and People Search results are served by the same search index now, you can choose which type of results you want here too.

Scrolling down the page, you have the ability to use the new Query Builder to construct a query. This new interface provides a lot of ways to create custom queries very easily.

The query builder lets you quickly construct a query even with dynamic values.

After you construct your query, you can click the TEST tab to see if the query works. There is so much to cover with the Query Builder, it will gets it own post in the near future.

Document Parsing

A number of improvements have been made to document parsing as well. New high performance IFilters exist for common Office document formats as well as images and PDF. This means you won’t have to manually configure that IFilter any more. However, the existing IFilter interface is available still in case there is anything you want to add.

Entity Extraction

In FS4SP, entity extraction was managed using a set of XML files. In SharePoint 2013 Preview, this has been moved to the term store. The out-of-the-box entity extraction will automatically extract company names out of documents. You can use the term store to manage exclusions and inclusions. Unlike FS4SP, it doesn’t look like you are able to add your own term sets for entity extraction, so this is unfortunate.

Schema Management

Managed Properties and Crawled Properties are now referred to as the Search Schema. Managed Properties have a number of new parameters such as allowing for sorting and refining that we gained from FS4SP.

Site Collection administrators now also have the ability to make changes to the search schema at their level. This allows you to delegate some of the search configuration to admins and let them override settings without affecting things globally.

Export and Import

Another one of my favorite features in Search is that we finally have the ability to export and import search configurations. I’ve only been asking for this since 2007. :) You can export your search configuration as XML and then import it later. This can even be done at the site collection level.

Crawl Log Permissions

There are times where you may want to grant access to the crawl logs to non-administrator users. The new setting allows you to grant other users access.

Querying

We’ll now look at some of the improvements when querying search.

Query Spelling Correction

Customizations to the Spelling Correction is now managed through the term store as well. This allows you to customize the “Did you mean?” functionality.

Query Rules

The new query rules engine lets you tailor your query results in ways never before possible. Each rule is composed of conditions and actions. When the conditions are met, one or more actions are implemented. Actions include things like promoting a result (similar to a best bet) and injecting a result block into the search results (basically changing the way search results look). I think a screenshot of the out-of-the-box query rules actually explains it better than I do.

In this example, if it finds a person name in the Local SharePoint Results, it will promote a result block showing people that matched the result. You can create your own query rules to really customize how search results look. You can even put start and end dates on a query rule.

User Interface

The User Interface has pretty much been rewritten in its entirety. It starts with the addition of the ResultScriptWebPart which retrieves and displays search results. This replaces the CoreResultsWebPart from SharePoint 2010 and has a ton of new functionality. Take a look at the search center in this example:

There is a lot to take in here. In my example here, I had a number of PowerPoint presentations returned. When I hover over one of them, it gives me a large visual preview of the slide deck that I can flip through. On top of that, it picked up the key sections of the document and listed them under “Take a look inside”. At the bottom of the preview there are useful links such as Follow (Social feature), Edit, View Library, and Send. What’s cool about the document preview is that it lets you scroll through the entire document. It even shows the animations in PowerPoint decks. If you used this functionality at all before with FS4SP, you might have been hit with the fact that document previews didn’t work against documents sitting on a claims-enabled web application. Note, that previews only work with claims authentication now (along with many other things).

There are a few remaining features to point out. On the left, you see some of the new visual refiners that allow you to search by different modified dates. The search box at the top also provides options to easily jump between documents, people, conversations, videos, and reports.

Result Types

In the above screenshot, you might have noticed that the PowerPoint results are formatted a certain way. This is through the new Result Type feature that allows you to customize how a particular result looks based upon a condition. As someone that customizes search, if there is anything to get excited about, this is it. Result Types are comprised of Rules, Properties, and Display Templates. The Rules define when the result type should be used (i.e.: Excel Documents, People, or Picture Library). When one of these rules matches, that Result Type will be used to display the individual result in a unique way. Properties refer to managed properties and these are what you will use in your display template to show the data from the result. Here is what the Result Types page looks like in the Site Collection.

You can edit the built-in result types, but you can create new ones. Before you define your result type, it is a good idea to create a new display template as you will have to select it from a list when creating the result type. The Display Templates are .js files and are kept in the ~sitecollection/_catalogs/masterpage/Display Templates/Search folder.

I’ll post soon about how to configure result types, but take a look at another example. This time I have a mixture of different document types. Most result types look the same out of the box, but you can customize them heavily to meet your needs.

Search Refinement

The refiner web part has some added functionality. It has the most of refinement included in SharePoint 2010. However, for those of you who used to use FAST ESP, we now have faceted navigation. This allows you to use refinement before you ever issue a search and is based upon data in the term store. Think of how BestBuy.com uses FAST ESP to allow you to select TVs –> >50” –> Plasma, etc. We can also leverage display templates to change how the refinement is rendered. This makes use of the new Refinable attribute that we see on managed properties. For example, that is how you see the data slider.

Query Suggestions

Query Suggestions have been improved largely through the use of the analytics component to analyze your personal search history. It actually weights results based on links you have previously visited. It also looks at the most frequent queries of all users to deliver better suggestion. There are two types of query suggestions: what you see before issuing the query and what you see along with the results. For the pre-query suggestions, you will get suggestions from your personal query log along with what other people have been searching for. For the suggestions after you get results back, it returns matches that you have clicked on at least twice. I’ll post more on this later after I have an environment that has been up long enough to capture some of this data.

API

The Search API has underwent a series of changes. Two new interfaces are available, while one was removed and another deprecated. If you write custom search code, you will want to pay attention to this section.

New Interfaces

The SharePoint REST API got some love in this release. In terms of search, we have a whole new interface for querying using REST. This is possible by calling the endpoint located at /_api/search. You can specify any site collection or site in the URL, but typically you’ll just go with the web application root URL. Specify any other URL prefix will get you the same results as well. In one of my upcoming posts, we’ll go into some real examples of how to use this new endpoint.

Search also got some love in the Client OM. That means you can now execute search queries using CSOM via JavaScript or .NET. According to the MSDN post, you can do mobile development as well, but I’m unsure if that includes Windows Phone. I am thinking it doesn’t but you can still use the REST API there. I’ll confirm that as I begin writing my posts on the API.

Removed and Deprecated

The Search API has been expanded greatly and you have some great new options to use. However, there are a few other changes you need to know about. First, and foremost, the SQL Syntax has been removed. I’ve been telling you for years to stop using it. At SPC09, they said it was unofficially deprecated and now I can say straight up that it is gone now. You also need to know that the Search web service (search.asmx) is now deprecated (but not gone) as well. That means you need to stop using the web service as it won’t work some day. If you need to remotely access Search, then use the Query CSOM or the Query REST Service which are much better and featured.

New Operators

If you have been using FAST Search for SharePoint, these three new operators will be nothing new to you. However, if you were strictly running SharePoint 2010, they may be of interest. Previously the XRANK operator was only available in FQL. Now we can use it in regular keyword queries and it gives us the ability to dynamically adjust the rank of items. The NEAR operator has been improved to include a configurable token distance (besides the default of 8) and a new ONEAR operator allows for ordered near functionality. Most of these operators are pretty hardcore so most people probably will never use them but they are there if you need them. You can also continue to use FQL if you prefer.

SharePoint Online

As Microsoft works to bring feature parity to SharePoint Online, the preview brings us a heap of new features in Search. Whereas you could configure next to nothing in the previous iteration of SharePoint Online, you can do just about anything with Search now. This comes from the new Search link inside tenant administration. From the list you see below, you can do just about anything except configure Content Sources. These are still handles automatically by SharePoint Online so we can’t change the frequency of crawls nor can we crawl other sources such as HTTP or BCS. Take a look at the Search settings in Tenant administration to get a feel for what you can do.

Scrolling down, we can adjust a few more settings.

I’ve already talked about Export and Import. The new Search Center Settings link allows you to set a global search center that will be used on each site. The feature parity in Search with SharePoint Online Preview is impressive. In fact, all of my screenshots for this article came from the cloud.

Summary

As I expected, this post has proved to be quite long. I tried to be brief in each section so as I could cover as much as possible. Anything in bold in this article will likely be a follow-up blog post, so stay tuned. I expect to find information that needs to be updated or points that I left out. I’ll be posting updates to this post as necessary. Anyhow, I hope this post has proved useful in explaining what you need to know about Search in SharePoint 2013 Preview.

Follow me on twitter at @coreyroth.

How to: Drag and Drop files into SharePoint 2013 Document Libraries

CoreyRoth — Tue, 17 Jul 2012 02:38:20 GMT

One of the simplest but most exciting features in SharePoint 2013 is the ability to drag and drop files into document libraries directly in the web browser. That means the user can drag a file off of his or her desktop and literally drag and drop it onto the browser and the file will upload. Here is what it looks like when you have the capability of drag and drop.

Note that it says you can “drag files here”. Here is what it looks like when you drag multiple files.

While the files are copying, you’ll see a screen like this.

This new feature is going to be one of the single most drivers of end user adoption hands-down. Now, you may be thinking…”That’s great, but I am sure it only works in IE.” If you thought that, you would be thinking wrong. I have tested it in a variety of browsers and have found that it has worked in every test I did with the exception of Internet Explorer 8 running on Windows Server 2008 R2.

Here’s what it looks like in Google Chrome.

I’ve even tried it in Safari on Mac OS X and it works there too. I would have included a screenshot of this but it was way too much effort to take it and get it back to my laptop. :)

I mentioned, it didn’t work for me in Internet Explorer 8 on Windows Server 2008 R2. This could be because of the server OS, because of IE8, or because I don’t have Office installed. That will require a bit more research. Here is what it looks like when drag an drop is not available.

Note, that “or drag files here” is not listed.

Now you might be wondering about how this works when content types with required fields are in place. Well, honestly, it could be handled better. The file is left checked out and it doesn’t really instruct the user to edit the properties and check the document in.

So for such a simple new feature, it is really quite exciting. I really think it will enhance productivity greatly. All screenshots were taken from SharePoint Online Preview.