Community members have noticed the cool new icons that have been appearing in our content. Here is an example:
This new icon set is the result of a huge joint effort by people in the Lync Server, Exchange Server, SharePoint, and Office groups here at Microsoft to support more visual styles of content.
For SharePoint, these new icons are used in the following:
To get these new icons for yourself, see the New Office Visio Stencil. Feel free to use them in your own content, including blog posts, articles, white papers, and videos.
For information about how to import them into Visio, see Import downloaded stencils.
Enjoy,
Samantha Robertson
If you're a website owner, you know how important it is that users can easily find your website by using Internet search engines such as Bing or Google. The higher your website is shown in the search results list, the more likely it is that users will click on it. Just think of your own behavior when looking at search results. When was the last time you clicked to view the second page of search results?
In the white paper, Optimizing SharePoint Server 2013 websites for Internet search engines, you can find out how you can apply SEO features to your SharePoint Server 2013 website, so that Internet search engines will display it high in their search results list. The white paper covers subjects such as:
The white paper is written by Waldek Mastykarz, Microsoft SharePoint Server MVP.
Many of you have used the "Fabulous 40 templates" that were created for Windows SharePoint Services 3.0. Some of these templates were created as site admin templates (.stp files) and some as server admin templates (.wsp files). Microsoft is not releasing new versions of these templates for SharePoint 2010 Products. Also, .stp files are deprecated and can't be used to create new sites when you upgrade to SharePoint Server 2010 or SharePoint Foundation 2010.
So, what do you do when you want to upgrade?
Sites based on these templates should upgrade, but you'll want to try out your upgrade in a test environment before you upgrade your production environment so that you can catch any potential issues. Definitely use the pre-upgrade checker to identify any issues (some people have seen problems with custom workflows or CAML-based views in the templates). However, after upgrade, you won't be able to use STP files to create new templates.
*There are issues with a few of the .wsp files after upgrade. In particular, after upgrading, some customers are unable to create new sites based on the following templates: Absence Request and Vacation Schedule Management, Call Center, Help Desk, IT Team Workspace, Knowledge Base, and Physical Asset Tracking and Management. If you have trouble using any of these templates, you can post an issue in the SharePoint 2010 – Setup, Upgrade, Administration and Operation TechNet Forum at http://social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/threads, or contact Microsoft Product Support.
So, what do you do if you're using an .stp file and you want to continue using it after upgrade? You can convert the .stp file to a .wsp file manually. To do this, in Windows SharePoint Services 3.0 or Office SharePoint Server 2007, create a site based on the template, and then upgrade the site to 2010. Then, follow this procedure:
If you can't or don't want to do that, you can look to the partner community for upgraded templates. Khalil over on TechSolutions has already converted some of these templates to 2010 for you. Take a look at http://techsolutions.net/Blog/tabid/65/EntryId/17/Fab-40-Templates-for-MOSS-2010.aspx.
This is a blog post in the series “How to display Recommendations and Popular items on a website”. In the previous post, I showed you how to add and configure the Recommended Items and Popular Items Web Part. In this blog post:
Note: The examples in this blog series are based on an on-premises installation.
Enable usage cookies to generate unique user IDsIn an earlier blog post I described how I arranged a “click party” to generate usage events. All users that participated in the “click party” were logged in. When users are logged in, each user has a unique user ID. In the event store file I was therefore able to verify that different user IDs were recorded for the usage events.
So how can usage events be recorded with a unique user ID when users are not logged in, that is, when they’re anonymous visitors? The answer is usage cookies. By default, usage cookies are not enabled for a SharePoint web application, but you can enable them. These usage cookies generate a unique GUID that is used as a user ID when usage event data is processed. The GUID is available for the lifetime of the cookie. The lifetime of the cookie is 14 days.
IMPORTANT: Local legal restrictions might apply when you enable usage cookies on websites that have anonymous users.
To enable usage cookies, do the following:
1. In Central Administration, click Manage web applications.
2. Select the web application that contains your publishing site, and click General Settings.
3. In the Web Application General Settings dialog box, in the Usage Cookie section, for Usage Cookie Status, click On.
4. Click OK to save your changes.
To verify that the Views usage events were correctly recorded on my Contoso website, I asked two colleagues to click around on my Contoso Electronics website. They were both anonymous users. I then started search analytics, and pushed the usage events to the Event store (I showed you how to do this in an earlier blog. In the usage event file, I verified that two different user IDs had been recorded.
Enable the recording of a usage event for anonymous usersWhen you enable usage cookies, only the Views usage event can be recorded for anonymous users. So, before you can record other usage events, for example Recommendation Displays, for anonymous users, you have to change a parameter value on the usage event.
The Options parameter specifies if the usage event can be recorded for anonymous users. For example, for the Views usage event, the Options parameter is set to AllowAnonymousWrite by default. This means that the Views usage event can be recorded for anonymous users.
For the Recommendation Displays usage event, the Options parameter is set to None by default. This means that the Recommendation Displays usage event can’t be recorded for anonymous users.
To enable the recording of a usage event for anonymous users, do the following:
1. On the server where SharePoint Server 2013 is installed, open the SharePoint 2013 Management Shell.2. At the Windows PowerShell command prompt, type the following commands:
# View the EventTypeId’s for all usage events:$SSP = Get-SPEnterpriseSearchServiceApplicationProxy$SSP.GetAnalyticsEventTypeDefinitions([Guid]::Empty, 3) | ft# Get a usage event:$tenantConfig = $SSP.GetAnalyticsTenantConfiguration([Guid]::Empty)$event = $tenantConfig.EventTypeDefinitions | where-object { $_.EventTypeId -eq <EventTypeId> }
<EventTypeID> is the number of the usage event that you want to enable for anonymous users, for example 2, which is the Recommendation Displays usage event.
# Enable the recording of a usage event for anonymous users:$event.Options = [Microsoft.Office.Server.Search.Analytics.EventOptions]::AllowAnonymousWrite$tenantConfig.Update($SSP)
# Verify that the recording of a usage event for anonymous users has been enabled:$event
After I enabled Recommendations Displays and Recommendations Clicked for anonymous users, I wanted to verify that these usage events were recorded. So, I again asked two colleagues to click around on my Contoso website. They were both anonymous users. I then started search analytics, and pushed the usage events to the Event store (I showed you how to do this in an earlier blog). Remember, in the Event store, each usage event type will be recorded in a separate file. Each file name starts with the EventTypeID, so a file name that starts with 1 contains the Views usage events. A file name that starts with 2 contains the Recommendations Displays usage events etc.In the Event store, I verified that three usage event types were logged. Nice!
So now you know how to configure and display recommendations and popular items on your website. If you want more details about the number of views for a specific item or category, you can do this by looking in the usage analytics reports on your catalog. I’ll show you how you can do that in the next blog.
Next blog post in this seriesView and configure usage analytics reports
Audience: Search Admin/ITPro Pre-requisite: This blog assumes the reader has basic SharePoint 2010 Search Administration knowledge.
If you’ve ever managed Search on SharePoint 2010 Products, chances are you’ve created Search Keywords and Best Bets. They are perhaps the easiest way to improve relevance on specific queries by letting you promote results to the top of the page, in whatever order you want. But in SharePoint 2013 Preview, you will not find the Manage Search Keywords link in Site Settings.
This is because Search Keywords have grown into something much more flexible: Query Rules. Here’s the difference.
The power of Query Rules is this generality. Instead of just matching specific queries, they let you infer what the user wants; instead of just promoting specific results, they can show whole other blocks of results relevant to the user’s query.
Yet if all you want to do is promote results to the top for a query — worry not! It’s as easy with Query Rules as it was with Search Keywords. In fact, if you’re upgrading from SharePoint 2010 Products, SharePoint 2013 Preview transforms all your old Search Keywords into Query Rules for you.
So let’s create a Query Rule that fires on the exact query ‘image library’ or ‘picture library’, then promotes a result for the Image Library to the top of the page.
First, we’ll go to the Query Rules management page. On your search center’s upper-right-hand corner, click the gear icon, then select Site Settings.
Next, on the Site Settings page, under the Search heading, click Query Rules. Note that you may see a Search Query Rules link under Site Collection Administration. This happens if you’re the Site Collection administrator and the search center is the site collection’s root site. Don’t click that one; those Query Rules affect every site in the site collection, and for now we want to focus only on the search center site.
Now that you’re on the Query Rules page, the first question to ask is “Where will the user be?” For example, do you want to manage Query Rules for your main Enterprise Search? Or for People Search? Or Video Search? Each search experience, out-of-the-box or custom, can have its own Query Rules.
This is what we call the query’s context. You configure Query Rules for a particular context by using that first row of dropdowns in the Query Rules management page.
To manage Query Rules for a specific search experience, use the first dropdown to pick the Result Source for that experience. We’ll go into Result Sources in another post — for now, think of them as a SharePoint 2010 Federated Location plus a Search Scope. Each search experience sends queries to a Result Source, and that source guarantees results meeting certain conditions. For instance, People Search sends queries to the Local People Results source, which only returns People results.
We want our new Query Rule to fire on the main Enterprise Search. That search experience sends queries to the Local SharePoint Results source (which includes everything SharePoint crawls except People). So choose Local SharePoint Results from the first dropdown.
Next, click Add Rule to start creating your new rule.
Having picked a context, we just need to give the rule a name, then specify its conditions and actions. In other words, say when this rule will fire, and what it will do when it does. This is very similar to creating a Search Keyword in SharePoint 2010:
And that’s it…you’ve created a Query Rule! To try it out, go to your search center and search for ‘image library’ or ‘picture library’ (note that it can take a few seconds for the Query Rule to start working).
This Query Rule, while simple, demonstrates the high-level steps for creating all Query Rules.
In our next Query Rules blog post, we’ll play with some more interesting conditions and show you a new kind of action: Result Blocks.
Audience: Search Admin/ITPro
The search schema is a mechanism in SharePoint search that controls:
What does this mean really? It means that the search schema controls what can be searched for, how it can be searched for and how the results can be presented in your search sites.
The most important concepts in search schema are crawled properties and managed properties.
The typical data flow is illustrated by this figure:
So a crawl component reads items from the content database (or other content sources) and sends documents and metadata to the content processing component in the form of crawled properties. A lot of magic then happens inside the content processing component: the text of the item is extracted, language detected, spell-checking applied etc. In addition, the content processing component maps crawled properties to managed properties and outputs a set of name-value pairs of managed properties. As an example, this process includes picking the best crawled property value to index as the author of a document. For e.g. a PowerPoint document this is usually stored inside the document. In other cases the author is found from other crawled properties. This process is defined through the built-in search schema and so-called mappings between crawled properties and managed properties. Some mappings are prioritized, meaning that the first crawled property that actually has a value is picked, while others are not prioritized and the values of all the crawled properties are mapped to managed properties and thus indexed.
The search schema contains a lot of system defined crawled and managed properties, as well as mappings in-between that are required for SharePoint Search to work properly. However, as an on-premises customer or SPO customer you also have the option to tweak the search schema to your liking.
With FAST Search for SharePoint 2010 and SharePoint Search 2010, only power users with the rights of Central Administrator could alter the built-in search schema. However, now in SharePoint 2013, even tenant admins and site collection admins/owners can modify their search schemas.
For SharePoint on-premises installations there are two levels that matter for search schemas: search service application (SSA) level and site collection level. This is illustrated in the schema hierarchy shown below:
When SharePoint 2013 is initially installed there exists only one search schema, which is accessible at the central admin level (aka "SSA level" since the central administrator owns the search service application). As before, the central administrator is free to make a number of changes at this level.
In a similar fashion, the site collection owners may choose to override their search schemas that they otherwise inherit from the SSA level. This structure provides opportunities for companies to create and use the search schema for cross-company standards that enrich company-wide searches while still allowing site collections flexibility.
For SharePoint online (SPO) there are three levels that matter for search schemas: search service application (SSA), tenant and site collection level. This is illustrated in the schema hierarchy shown below:
In SPO, the SSA level is pre-defined (and the same as the default on-premises SSA level search schema). This schema may only be changed by Microsoft. However, new in SharePoint 2013 is the possibility for tenant administrators to modify this centrally defined schema for their tenant. Each tenant administrator inherits from this schema and may choose to override it with various types of changes (described further below).
In a similar fashion, the site collection owners may choose to override their search schemas that they otherwise inherit from the tenant level. This structure provides for opportunities for tenants to create and use the search schema for cross-company standards while still allowing site collections flexibility.
Central administrators have the most freedom for search schema changes. Besides properties that are system defined or read-only and required for SharePoint 2013 to work properly, they can add, remove, change and delete any crawled property, managed property or mapping.
Tenant administrators as well as site collection owners have the ability to:
The combination of the latter two operations is powerful. If your intent is, for example, to make an existing managed property refinable, this is not something you are allowed to do on a site collection level. However, what you should do instead is:
Use the default unused managed properties for step two above.
This is more than enough theory in one blog posting, so let's move over to an example: We would like our site collection search page to use something else for the title of documents. This is just for fun and not considered best practice in any way.
We will go through the following steps to accomplish this:
Prerequisites: You need to have a site collection available to perform this step. If you do not have that, log in as central administrator or tenant administrator and choose create site collection from Central Admin. For this example we will create a site under /sites/botanical, with template "team site".
Next, we log in as the owner of the site collection and create a list by clicking on:
Site contents -> Add an App -> Custom list
We call the list "flowers" and add a custom column of type string called LatinName. Then,we populate the list with a few items to make it look something like this:
Any site by default has a search box. This box appears in the upper right corner of your site like this:
When searching, a result page such as this one appears:
Notice that there are three refiners on the left-hand side: result type, author and modified date. For each result in the result list there is a header with a larger font, then an extract of the text of the item, with the search keyword(s) highlighted, followed by the URL.
If you cannot see the list items from step 1 in your list of search results, you probably need to wait for a crawl to pick them up and index them. On most systems this will happen automatically during the next 30 minutes. Do not let that stop you, but move on to the next step and see if that works. If you are central administrator you can trigger the recrawl from Central Administration -> Manage Service Applications-> Search Service Application -> Content Sources -> Local SharePoint sites -> Start Full Crawl.
To change the search schema, open Site Settings from the menu on the upper right:
Then select Search Schema under the Site Collection Administration heading:
This now displays the list of available managed properties on this site collection:
Next, click on the managed property we're about to alter, "Title", to edit it. You will then see all the various attributes for Title, many of which are read-only on a site collection level. Scroll down to the mappings section of the page:
Here a number of crawled properties are mapped in prioritized order. The first of these crawled properties that have a value will be indexed as the value of Title, and it is shown in our search results.
Next, click "add a mapping" and select ows_LatinName from the list of crawled properties. It is possible to type in part of the name to avoid scrolling down the whole long list:
"ows_LatinName" is the crawled property that corresponds to the LatinName column we just created in the Flowers list. Press OK and you are back to editing the Title managed property.
Now you need to press the "Move Up" button several times to make sure that this crawled property is at the top of the list and thus has the highest priority.
Then press "OK" at the end of the page to store the changes to the Title managed property.
Congratulations! You have now created a customized schema for this site collection. This was not possible in SharePoint 2010.
After only altering the schema mappings not much has happened in the search index. This is because the altered mappings take effect as part of the document processing, which only occurs when documents are processed as part of a crawl. To see the effect of our change we need to make sure the list items are recrawled and the items reindexed. We can force a recrawl of our document library like this:
This marks the whole list to be picked up by a continuous crawl, regardless of whether the items have actually changed. The next time a continuous crawl comes and checks your list for changes it will refeed them all.
Warning: If your system is not set up to perform continuous crawls you need to wait for the next recrawl as scheduled by your administrator. Alternatively, if you are central administrator you can trigger the recrawl from Central Administration -> Manage Service Applications-> Search Service Application -> Content Sources -> Local SharePoint sites -> Start Full Crawl.
Crawls are not instant, so we need to wait until a crawl has read our document library and resubmitted the documents to the content processing component. Only then will the index receive the results of our schema changes. If you are testing this with central admin rights you can go to the "manage content sources" page inside the management pages for the search service application and look at the status of the crawl.
Now that documents have been recrawled and reprocessed according to our new schema, we can look at the new search results. Performing a test search in the site collection search box gives us a result set such as the one below:
As you can see, the second item in this list of results is the list item from our list (and the first is the list itself). For this second item we can see that the title now is the Latin name from our list and not the title of the item. Here is how it used to look:
This is certainly a subtle change, but it demonstrates that we have created a custom schema to change how items are indexed and how results are displayed. The custom schema we created only applies to a single site collection, so we have tested the ability to have multiple search schemas in SharePoint 2013! In a later posting we might even use this capability to do something really useful for search.
Other articles with references to schema management:
With Microsoft’s cloud strategy and engineering investment into Office 365, one SharePoint 2013 feature is a rising star: host-named site collections.
Host-named site collections are how Microsoft achieves scale in its multi-tenant environment. New features and existing features are optimized to work with host-named site collections like never before. However, it’s not just the feature that is important. It’s how it is configured — all host-named site collections are deployed to a single web application. The App model and Request Management, for example, are optimized for this configuration.
Being the author of many of the logical architecture design samples and articles that told you to isolate different types of content into different web applications, I recognize how disruptive this new recommendation might be for those of us who are SharePoint troupers. Nevertheless, the argument for moving in this direction is compelling. Because we run this configuration in our Office 365 environment, it is the most comprehensively tested and reliable configuration going forward.
Host-named site collections require more sophistication than the alternative, path-based site collections. It’s all described in a new article — Host-named site collection architecture and deployment (SharePoint 2013).
I’m proud to say that this article is the result of a close partnership with one of Microsoft’s field solution architects — Timo Heidschuster — who has implemented many production-level solutions using host-named site collections. Timo’s customers are early adopters of SharePoint 2013. He has been working with this feature set for several product versions and he provided valuable feedback to the product team throughout the release cycle. Timo provided the Windows PowerShell scripts and much of the guidance based on his experience in the field.
Since the emphasis on using host-named site collections is relatively new, feel free to use this blog post to ask questions, comment on the article, request more information, or simply vent.
Brenda Carter, Long-time SharePoint Writer
This is a blog post in the series "How to change the way search results are displayed in SharePoint Server 2013." To demonstrate how you can customize your search results, I'll use examples from an internal Microsoft Search Center.
For an overview of the blog posts in this series, go to How to change the way search results are displayed in SharePoint Server 2013.
In the previous blog post, I explained how item display templates and hit highlighting work. In this blog post we'll learn:
About the Search Center example in this series
To help explain how you can customize the way search results are displayed, I’ll use examples from a tool that I use on a daily basis: an internal list of Microsoft publications.
As you know, Microsoft publishes thousands of articles across TechNet, MSDN and office.com. To assist in the publishing process, we use several SharePoint lists. Each item in a list represents an article or a media file. To make it easy to find information about a particular list item, we created a Search Center that searches across these lists.
In our first version of the Search Center, all the search results were displayed identically. This was because by default, all list items belonged to the same SharePoint List Item result type. We wanted to change this so that just by glancing at the search results, we could distinguish between an article published on TechNet and an article published on MSDN. We also wanted to add important information about each search result that would be visible without having to select and open it.
Before we did anything in SharePoint, we sat down for a planning session. The first step was to decide how we wanted to categorize our search results. We came up with the following categories:
Once we had defined the categories, we then needed to distinguish the categories from each other. Items in our list contain a site column named Distribution Channel. This site column contains the value of the platform to which an article has been published, for example TechNet Library.
We decided that we would use values from the Distribution Channel site column to distinguish the categories from each other.
With these decisions in hand, I set out to create new result types for each of the categories. The procedure for creating a new result type is identical for all categories, so to save space, I will only show you how I created the TechNet content result type.
How to copy a default item display template
Before you create a new result type, you should create a new item display template that your new result type will use. To avoid having to create a new item display template from scratch, you can copy an existing one. Try to copy an item display template that is as close as possible to the type of content you have. Here's what you should do:
In my scenario, I wanted to customize search results for SharePoint list items. From this reference table I was able to determine that the default item display template that is used by the SharePoint List Item result type is the file named Item_Default. Because I had mapped my network drive, I could easily copy the Item_Default file in Windows Explorer.
By refreshing Windows Explorer, I could see that SharePoint had automatically created an associated JavaScript file.
In my scenario, I renamed it TechNet content. Again, I refreshed Windows Explorer to verify that the JavaScript file was updated accordingly.
In my scenario, I changed the <title> tag to TechNet content.
Now that we have created a new item display template, we can move on to creating a new result type.
How to create a result type
Depending on your permission level, you create a result type on two levels:
To save space, I will only show you how to create a result type as a Site collection administrator.
Instead of creating a new result type from scratch, you could make your life a bit easier by copying an existing result type and modifying it to fit your new result type. If you do this, ensure that you copy a result type that closely resembles the new result type you want to create.
In my scenario, I wanted to customize search results for SharePoint list items, so I copied the SharePoint List Item result type.
This opens up a menu where you can specify the result type based on managed property values.
In my scenario, all list items contain a site column called Distribution Channel. As I showed you at the beginning of this blog, this site column contains the publication platform value, for example TechNet Library. I wanted to use values from this site column to specify which list items should belong to my new result type
Your newly created result type is now listed on the Managed Result Types page. In my scenario, I could see that the TechNet content result type had been created.
So now that we have a new result type, the next step is to modify the display template that is associated with this result type. There are different ways you can go about doing this, so in the next two blog posts, I'll explain two different options.
Next blog post in this seriesHow to display values from custom properties in search results - option 1
Additional ResourcesConfigure result sources for search in SharePoint Server 2013Result types and display templates that are used to display search results in SharePoint Server 2013
One of the best ways to know what databases your SharePoint deployment uses is to keep a record and add database names each time you create a new database.This isn’t always easy as there usually isn’t enough extra time during the day to keep records. Plus, more often than not your SharePoint database maintenance tasks tend to occur either late at night or in the pre-dawn hours when no users are accessing the system, so remembering to add a new database name to an ongoing list is really tough.
Luckily, there are several tried and true methods you can use to find not only the active databases used in your SharePoint environment but also find the properties for each.
In the Application Management section just click Manage content databases to go to a page that lists content databases used in your farms.
This is a good way to find the databases but isn’t always feasible for one reason or another. Since SQL Server Management Studio lists all databases, it can be hard to out which ones are the SharePoint Server databases.
If you want a report of all of your SharePoint databases that includes the GUIDs and related property values, use the SharePoint 2010 Management Shell.
There are several Windows PowerShell cmdlets you can use to find all of the SharePoint databases and then print this report to a text file. The quickest and perhaps easiest cmdlet is “Get-SPDatabase”. Run this cmdlet in the SharePoint 2010 Management Shell to list all of the SharePoint Server databases with properties for each one. From this potentially large list you can then obtain specific information such as the database ID by using additional syntax in your cmdlet. Similarly, also in the SharePoint 2010 Management Shell, run “Get-SPDatabase | Sort-Object disksizerequired -desc | Format-Table Name” and you will get a simple list of the names for each database. You can then print this list to a text file by adding, “| out-file c:\db.txt” to the end of the command. For detailed information, see Windows PowerShell for SharePoint Server 2010, Database cmdlets, Get-SPDatabase, and Get-SPContentDatabase.
In Central Administration, in the Backup and Restore section, access Perform a backup. This page lists all of the items that you can backup in your farm. In this list are all of the databases used by SharePoint Server. Just expand all of the components and then look through the Type column to find the SharePoint database names. Of course, if you do not want to perform a backup, just click Cancel after you’ve listed all of the databases in your SharePoint farm.
Credit for some of these tips goes to where I discovered them, in the SharePoint 2010 – General Questions and Answers forum.
Thanks for reading,
Steve Hord, Technical Writer, SharePoint Content Publishing
To all the loyal SharePoint enthusiasts who have come to know and love the SharePoint IT Pro Blog, thank you for all your past comments and engagement with us. This blog would not have continued to thrive without your participation. However, as Microsoft moves toward frequent updates across all Office products, we’ve decided to consolidate our posts into the Office blogs platform to make it easier on you to find information across all Office applications. As of today, there will no longer be new posts to the SharePoint IT Pro Blog. To find the latest news and announcements related to SharePoint, please refer to Office Blogs at blogs.office.com.
Please see this post on the new Office blog for information on how to filter and personalize the site for the specific content that you want to see.
Thank you and we look forward to reading and responding to your comments on Office blogs!
-- The SharePoint IT Pro Blog team
Integrating social media within your organization can help you reach your organization’s goals. The integration can be done on your organization’s intranet to increase transparency, but you can also make social networks a part of your public-facing website to expand reach and increase conversion of your website.
This post is written by Waldek Mastykarz, Microsoft SharePoint Server MVP.
Integration with social media has become a hype in the last few years. Many organizations want social networks to be integrated with their public-facing website without a clear understanding of what such an integration means, and how it should support the organization’s goals. This article is not about helping you form a vision for leveraging social networks within your organization. Instead it presents a number of different integration scenarios, and shows how you can benefit from them. Eventually it is up to you to make an educated choice about which of these integration techniques will work for your scenario, and how the integration should look.
From the communication perspective you can integrate with social media in two ways:
This article will focus on the first option.
Integrating with social media is all about reaching as many people as possible. Information about the content on your website, whether it is articles, blog posts or products, when discovered and found valuable, it can be shared by your visitors with their friends, who again might share it with their friends. Before you know it, your content will reach people that otherwise might not have even known about the existence of your website. However, for this to happen, you have to ensure that when your content is shared on social networks, it looks exactly the way you want it to look.
Just as you can optimize your web content for Internet search engines, you can provide some meta information about your content for the purpose of social networks. Many social networks such as Facebook or Yammer use the Open Graph protocol (http://ogp.me/) to retrieve information about your content. To control how your content is displayed when it is shared on social networks, you have to integrate Open Graph metadata into your website. The metadata should describe the essence of your content, so that anyone who sees your content on a social network will want to click on it.
Publishing Open Graph metadata for a website that is built with SharePoint 2013 isn’t complex, but there a few things that you should consider. First of all Open Graph defines different types of web content – similar to what you can achieve with Content Types in SharePoint. Before you start integrating Open Graph into your website, you should have a clear understanding of what types of content you have on your website, and how it can be described most effectively by using Open Graph.
Next to the different types of content that you can publish on your website, there are also differences in how that content is published. SharePoint 2013 offers two content publishing models:
These publishing models have two different ways of publishing content and, depending on which one you are using on your website, you should plan for publishing the information according to your content publishing model.
Open Graph information is published using HTML meta tags. Those tags must be located in the head section of your website. To support publishing different Open Graph information for different types of pages and content publishing models, you should define a Content Place Holder in your Master Page. This will allow you to fill that placeholder with the appropriate metadata from within the different Page Layouts.. The following code snippet shows a Content Place Holder added to the standard seattle.master Master Page to support publishing Open Graph information:
<head>
…
<!--MS:<asp:ContentPlaceHolderid="OpenGraphPlaceHolder" runat="server">-->
<!--ME:</asp:ContentPlaceHolder>-->
</head>
According to the Open Graph protocol there are four properties that are required for every web page: title, type, image and URL. Although Open Graph defines a few content types, if you are not publishing information about video or audio, the odds are high that you will be using the article type for the majority of your web pages. Because not every page is an article, you might want to use the website type. The website type is the default type if no type is specified. To simplify working with Open Graph we could expand the code snippet above by adding the information about the title, URL and type. This would prevent us from repeating the same code snippet within each Page Layout.
Although the basic Open Graph information is a part of the SEO information published by SharePoint 2013, standard SharePoint 2013 SEO controls cannot be used directly to render this information on Master Pages and Page Layouts as Open Graph meta tags. To use those controls for the purpose of publishing Open Graph metadata, I have built a set of wrapper controls and published together with this article to illustrate how you can build similar wrapper controls.
By leveraging Search Engine Optimization capabilities of SharePoint 2013 we can retrieve the information about the page as follows:
<!--SPM:<%@Register Tagprefix="Contoso"Namespace="Contoso.SharePoint.Seo.Controls"Assembly="Contoso.SharePoint.Seo, Version=1.0.0.0, Culture=neutral,PublicKeyToken=a285ef6967f781d3"%>-->
<!--MS:<Contoso:TemplatedControlWrapperrunat="server">-->
<Control>
<controltype="Microsoft.SharePoint.Publishing.WebControls.SeoBrowserTitle"assembly="Microsoft.SharePoint.Publishing, Version=15.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
</Control>
<ContentTemplate><metaproperty="og:title" content="$Value$"/></ContentTemplate>
<!--ME:</Contoso:TemplatedControlWrapper>-->
<!--MS:<Contoso:HyperlinkControlWrapperrunat="server">-->
<controltype="Microsoft.SharePoint.Publishing.WebControls.SeoCanonicalLink"assembly="Microsoft.SharePoint.Publishing, Version=15.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
<ContentTemplate><metaproperty="og:url"content="$Url$"/></ContentTemplate>
<!--ME:</Contoso:HyperlinkControlWrapper>-->
<meta property="og:type content="article"/>
This approach assumes that you want the title of your page to be published on social networks in the same way as it is displayed in the title bar of a web browser. Should your scenario differ, you can replace the contents of the title propertywith a suitable alternative, or remove it and have it filled from within the OpenGraphPlaceHolder content placeholder.
The great benefit of leveraging the standard SharePoint 2013 Search Engine Optimization controls, as shown above, is that they work for both classic as well as search-driven content publishing model and will automatically retrieve the necessary content using the necessary approach.
The next step is to provide the page-type specific information according to the Open Graph protocol. For pages using the classic publishing model you can use Publishing controls to retrieve the content, for example:
<!--SPM:<%@RegisterTagprefix="Contoso"Namespace="Contoso.SharePoint.Seo.Controls"Assembly="Contoso.SharePoint.Seo, Version=1.0.0.0, Culture=neutral,PublicKeyToken=a285ef6967f781d3"%>-->
<controltype="Microsoft.SharePoint.WebControls.FieldValue"assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral,PublicKeyToken=71e9bce111e9429c" FieldName="PublishingContactProfileUrl"/>
<ContentTemplate><metaproperty="article:author"content="$Value$"/></ContentTemplate>
When using search-driven publishing you would use Catalog Item Reuse Web Parts instead:
<!--SPM:<%@RegisterTagprefix="Contoso "Namespace="Contoso.SharePoint.Seo.Controls"Assembly="Contoso.SharePoint.Seo, Version=1.0.0.0, Culture=neutral,PublicKeyToken=a285ef6967f781d3"%>-->
<controltype="Microsoft.Office.Server.Search.WebControls.CatalogItemReuseWebPart"assembly="Microsoft.Office.Server.Search, Version=15.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c"UseSharedDataProvider="True"SelectedPropertiesJson="["PublishingContactProfileUrlOWSTEXT"]"/>
<ContentTemplate><metaproperty="article:author" content="$Value$"/></ContentTemplate>
When using cross-site publishing, in most scenarios the content of the detail pages, called catalog item page, is surfaced from the search index and can be retrieved as shown above.The content of overview pages, called category pages, is determined by the information coming from the Managed Metadata Service. Should you need to retrieve information from your taxonomy to render it as part of your Open Graph manifest, you can do so by using the TermProperty control:
<!--SPM:<%@RegisterTagPrefix="Taxonomy"Namespace="Microsoft.SharePoint.Taxonomy"Assembly="Microsoft.SharePoint.Taxonomy, Version=15.0.0.0,Culture=neutral, PublicKeyToken=71e9bce111e9429c"%>-->
<controltype="Microsoft.SharePoint.Taxonomy.TermProperty" assembly=" Microsoft.SharePoint.Taxonomy,Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"PropertyName="Title" />
<ContentTemplate><metaproperty="article:section"content="$Value$"/></ContentTemplate>
Different social networks support different meta data. Depending on which social network you want to integrate with your website, you should verify the relevant API. By using the techniques showed above, you can provide relevant information about your web pages, and ensure proper presentation of your content on social networks.
Having configured the basic information about our web pages, let’s explore the different integration capabilities offered by social networks. For brevity we will focus on Facebook, but presented mechanisms could apply to other social networks as well.
Facebook offers a number of standard plugins that you can use to integrate with Facebook on your website. The overview of all available plugins is published at https://developers.facebook.com/docs/plugins/. Following is an overview of some of the plugins and how you can integrate them with your website.
When integrating with Facebook, you can add one or more widgets to your website. Although this will allow your visitors to interact with your website using Facebook plugins, it will provide you with very little feedback about how your visitors leverage the social media capabilities that you have provided them with. The great news is that if you want to get more information about the usage of Facebook social plugins on your website, you can benefit from the Insights capability that Facebook offers you. After registering your website as a Facebook app and including the app ID in your website, you will get access to analytics information regarding the usage of Facebook on your website from all the widgets.
More information about Facebook Insights is available at https://developers.facebook.com/docs/insights/
The Facebook Like button is probably the most popular Facebook social plugin. With a single mouse click your visitors can let their friends know that they like a page on your website. As a result your page and even your whole website might get some extra attention.
Although you might want to include the Like Button on every page on your web page, it might be most effective on detail pages that contain the essential content your visitors are looking for. Integrating the Facebook Like Button on your website is easy and comes down to including two HTML snippets in your websites.
First there is the Facebook SDK call that should be included once per page directly after the body tag:
<div id="fb-root"></div><script>(function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "//connect.facebook.net/en_US/all.js#xfbml=1"; fjs.parentNode.insertBefore(js, fjs);}(document, 'script', 'facebook-jssdk'));</script>
If you have registered your website as a Facebook app, you should include your app ID (underlined) in this snippit:
<div id="fb-root"></div><script>(function(d, s, id) { var js, fjs = d.getElementsByTagName(s)[0]; if (d.getElementById(id)) return; js = d.createElement(s); js.id = id; js.src = "//connect.facebook.net/en_US/all.js#xfbml=1&appId=0123456789"; fjs.parentNode.insertBefore(js, fjs);}(document, 'script', 'facebook-jssdk'));</script>
Because this HTML snippet is shared between all pages on your website, the way to include it in your SharePoint website is to make it a part of your Master Page, as shown in figure 1.
Figure 1. Code snippet Master Page with Facebook code included
The second code snippet that you have to include is the Like Button itself:
<div class="fb-like" data-href="http://www.contoso.com" data-send="true" data-width="450" data-show-faces="true"></div>
Because the placement of the Like Button might vary per page, the best way to integrate it on your website is to include it in the Page Layout.
According to the Like Button guidelines, the Like Button has to contain the absolute URL of the page on which it is integrated. In the code sample above the absolute URL is included in the data-href attribute. Because we want to place the code on the Page Layout we don’t want to include a fixed URL. Instead we want to inject the URL of the current page rendered using thePage Layout. Considering that SharePoint 2013 offers support for physical as well as Friendly URLs, the best way to get the URL of the current page is to use the SharePoint 2013 Canonical URL control. Combined with the Like Button HTML code snippet, it would look as follows:
<!--SPM:<%@Register Tagprefix="Contoso" Namespace="Contoso.SharePoint.Seo.Controls" Assembly="Contoso.SharePoint.Seo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a285ef6967f781d3"%>--><!--MS:<Contoso:HyperlinkControlWrapper runat="server">--><Control> <control type="Microsoft.SharePoint.Publishing.WebControls.SeoCanonicalLink" assembly="Microsoft.SharePoint.Publishing, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /></Control><ContentTemplate> <div class="fb-like" data-href="$Url$" data-send="true" data-width="450" data-show-faces="true"></div></ContentTemplate><!--ME:</Contoso:HyperlinkControlWrapper>-->
Figure 2. Facebook Like button
When building the Like Button social plugin an interesting option worth considering is including the Send option.
Although designed using a very simple idea, integrating the Like Button on your website can help you expand the reach of your content. An additional benefit that you get from using the Like Button on your website is that combined with the SharePoint 2013 Search Analytics capabilities, you can leverage the event of someone liking a web page on your website. With this information you can for example present content that has been liked on a prominent place on your website, which again increasing your chances for conversion.
When building the Like Button social plugin an interesting option worth considering is including the Send option. While clicking the Like option allows your visitors to share your web page with everyone, they can use the Send button to choose with whom they want to share your web page. This offers them more flexibility and lowers the bar for sharing the contents of your website even further.
Figure 3. Facebook Send button
Publishing original content is a great way for gaining popularity and improving the ranking of your website in search engines. Furthermore, allowing your visitors to provide you with feedback, can help you improve your website to be even more user-friendly and become better tailored to your audience’s interests. Facebook offers the Comments plugin that you can integrate with your website to allow your visitors to comment on your website.
Figure 4. Facebook Comments
Giving your visitors the ability to use Facebook to comment on your content, can be of great benefit both to you and your visitors. Although it might depend on the audience of your website, many people have a Facebook account nowadays. It is easier for them to use their existing Facebook profile to leave a comment on your website rather than following yet another registration process.
Another benefit of using Facebook for comments is that whenever someone comments on your content, that comment will be shared with their friends. Theoretically this allows you to expand your reach even further. However, keep in mind that if the comment isn’t flattering everyone will know it as well.
The process for integrating the Facebook Comments plugin is very similar to integrating the Facebook Like Button. In most scenarios you want the Facebook Comment plugin to appear beneath the content of every page. To do this, you can include it in the content of each Page Layout used within your website.
Similarly to the Facebook Like button, the Comments plugins consists of two code snippets. The first one is exactly the same as for the Facebook Like button, so if you plan to integrate both plugins, you only have to include it once.
The second snippet is the Comments plugin itself. It should be placed where you want it to be displayed in your Page Layout:
<div class="fb-comments" data-href="http://www.contoso.com" data-width="470" data-num-posts="10"></div>
Similarly to the Facebook Like button, the data-href attribute should contain the absolute URL of the page for which you want to provide the commenting capability. As this is very likely to be the current page, you could once again benefit of the SeoCanonicalLink control to retrieve the URL of the current page:
<!--SPM:<%@Register Tagprefix="Contoso" Namespace="Contoso.SharePoint.Seo.Controls" Assembly="Contoso.SharePoint.Seo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a285ef6967f781d3"%>--><!--MS:<Contoso:HyperlinkControlWrapper runat="server">--><Control> <control type="Microsoft.SharePoint.Publishing.WebControls.SeoCanonicalLink" assembly="Microsoft.SharePoint.Publishing, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /></Control><ContentTemplate> <div class="fb-comments" data-href="$Url$" data-width="470" data-num-posts="10"></div></ContentTemplate><!--ME:</Contoso:HyperlinkControlWrapper>-->
Another interesting plugin that Facebook offers for integrating its capabilities on public-facing websites is the Activity Feed plugin.
The Activity Feed plugin shows the recent activity on your website. Whenever someone likes a page within your website, the Activity Feed plugin is used to display the Like in the Activity Feed. Other custom actions custom can also be recorded, stored and presented in the Activity Feed.
Using the Activity Plugin can help your visitors discover new content and with that help you expand the reach of your website. When your visitors are logged in with Facebook, the Activity Feed will show activities that your visitors’ friends have made. As in most situations those are all people that your visitors know and trust. Therefore, the odds are high that they will follow their recommendations and discover new content on your website. If they are not logged in on the other hand, the Activity Feed plugin will show recommendations from across your site and of course suggest logging in to Facebook to show more relevant content.
As with other Facebook plugins, the Activity Feed plugin consists of two HTML snippets required to integrate it with the website. The first one is the Facebook JavaScript SDK snippet that we have seen previously. The second one is the Activity Feed itself:
<div class="fb-activity" data-site="contoso.com" data-width="300" data-height="300" data-header="true" data-recommendations="false"></div>
The configuration of the Activity Feed is straight-forward. Using the data-site attribute you have to specify the domain of your website, and which activity information should be displayed. Using other data attributes you can control the user experience of the Activity Feed on your website, and whether you want to explicitly include recommendations or not.
Although you could place the Activity Feed on every page on your website, there is a chance that this would work against you and distract your visitors from your content. Because the Activity Feed allows you to expand the reach of your website, it might be a better idea to analyze your web analytics data and place the Activity Feed somewhat more strategically, forexample on the frequent exit pages and landing pages such as the home page.
Because in most scenarios you will embed the Activity Feed on specific pages, the best way to integrate it with your website is not to include it in the Master Page or Page Layouts, but to add it to the specific pages. The best way to do this is to embed the Activity Feed code snippet in the page using the Script Editor Web Part.
Figure 5. Embed code
A slightly different, nevertheless very interesting, plugin is the Recommendations Bar. This plugin can also help you expand the reach of your website by displaying recommended content. What’s different about the Recommendations Bar is its usage scenario.
The Recommendations Bar is located at the bottom of the browser window. Depending on its configuration it might become visible after a certain amount of time, for example after users have scrolled past a certain point of the page. This plugin can be very useful because it provides your visitors with suggestions of additional content they might find interesting.
When integrating the Recommendations Bar on your website, you should consider integrating it with the detail pages. That way, when your visitors have finish consuming the current content, they are offered a next step. Once again this plugin requires the reference to the Facebook JavaScript SDK to work. The plugin itself is represented by the following markup:
<div class="fb-recommendations-bar" data-href="http://contoso.com/articles/my-article/"></div>
Because you want recommendations to be visible on every page, you should add it to the Page Layouts used by your detail pages. Following is the markup that you should add to your Page Layouts to ensure that the Recommendations Bar will work for every page. Notice how the contents of the data-href attribute are being set dynamically by using the SeoCanonicalLink control we discussed previously:
<!--SPM:<%@Register Tagprefix="Contoso" Namespace="Contoso.SharePoint.Seo.Controls" Assembly="Contoso.SharePoint.Seo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a285ef6967f781d3"%>--><!--MS:<Contoso:HyperlinkControlWrapper runat="server">--><Control> <control type="Microsoft.SharePoint.Publishing.WebControls.SeoCanonicalLink" assembly="Microsoft.SharePoint.Publishing, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /></Control><ContentTemplate> <div class="fb-recommendations-bar" data-href="$Url$"></div></ContentTemplate><!--ME:</Contoso:HyperlinkControlWrapper>-->
Like all other content, the recommendations that are displayed by the Recommendations Bar are controlled by the activity on your website, and recorded by Facebook. Although the Recommendations Bar will display personalized content suggestions, it doesn’t offer you any control regarding what content will be displayed where. Although the differences in which items are suggested as recommendations might be subtle, they could decide whether or not your visitors will remain on your website.
An alternative to integrating the Facebook Recommendations Bar that is worth considering is using the content recommendations capability provided with SharePoint 2013. Although it would require some customizations to achieve similar user experience as the one that Facebook Recommendations Bar has, the great advantage is that you can control which content is displayed as recommendations. Because content recommendations are based on SharePoint 2013Search, you can leverage all of its capabilities to ensure that the most relevant recommendations are displayed to your visitors.
If your organization offers products or services to consumers, integrating with Facebook might be a wise choice. If however your business is more based on knowledge and is targeted at other businesses, it might be worth the effort to integrate with Yammer as well. To put it simple: Yammer is Facebook for enterprises. It helps organizations share their knowledge by allowing them to communicate within the boundaries of their organization. Making it easier for your visitors to share the content from your website with their Yammer networks might help you reach more of your business customers.
Although Yammer doesn’t offer as many plugins as Facebook does, one thing that you could easily include in your website is a Yam it button. The Yam it button allows your visitors to share the page that they are currently visiting with theirYammer network with a single mouse click. Following is sample code of a Yam it button:
<a href="javascript:var d=document,w=window,e=w.getSelection,k=d.getSelection,x=d.selection,s=(e?e():(k)?k():(x?x.createRange().text:0)),f= 'https://www.yammer.com/home/bookmarklet',l=d.location,e=encodeURIComponent,p='?bookmarklet_pop=1&v=1&u='+e(l.href)%20+'&t='+e(d.title.replace(/^ *| *$/g,''))%20+'&s='+e(s),u=f+p;a=function()%20{if%20(!window.open(u,'sharer','toolbar=0,status=0,resizeable=1,width=650,height=550'))l.href=f+p};if%20(/Firefox/.test(navigator.userAgent))setTimeout(a,0);else{a()}void(0);">Yam it!</a>
The Yam it button is completely based on JavaScript so you can include the above snippet directly in SharePoint without modifying it. From the integration perspective the Yam it button can be best compared with the Facebook Like button, so wherever you feel it is right to include the Facebook Like button, it is probably a good place to include the Yam it buttonas well.
Figure 6. Yam It! button
Integrating social networks with your website can help you expand the reach of your website and help your visitors discover new content. Most social networks offer standard plugins that can be easily integrated within your content management system. SharePoint is no exception here. No matter if you want to integrate social media only on some specific pages or allpages of a particular type, SharePoint offers you the flexibility to do so effortlessly.
Scenario: Create SharePoint sites by using cross-site publishing in SharePoint Server 2013
Step-by-step instructions: How to set up a product-centric website in SharePoint Server 2013
Custom SharePoint SEO controls
Leveraging internal controls and APIs using wrapper controls
Waldek Mastykarz is a Microsoft SharePoint Server MVP and works as a SharePoint consultant at Mavention. Waldek shares his enthusiasm about the SharePoint platform through his blog, articles published in online and off-line magazines and on MSDN SharePoint Forums. He is also a speaker at community events such as the SharePoint conference in London, SharePoint Connections Amsterdam, and SharePoint Saturday. In addition to his job at Mavention, Waldek is a Virtual Technology Solutions Sales Professional for Microsoft Netherlands. In this role he helps answer customer questions around SharePoint Web Content Management (WCM).
Blog: http://blog.mastykarz.nl Twitter: http://twitter.com/waldekm Mavention: http://www.mavention.com
If you're using a SharePoint product then you've probably got some sites to manage — sites you've created, sites your users have created, and sites other administrators have created. Maybe some of these sites are tracking small projects that will outlive their usefulness in a short amount of time. There might even be more than a few sites that no one uses anymore, and those sites may have content or even site mailboxes that are just taking up space.
Wouldn't it be great if there was a way to apply retention policies to sites in the same way you do with items in your sites? We've got just the thing — Site Policy for SharePoint Server.
Site Policies allow you to create a retention policy that can be applied to a site. Site Policy includes the following options:
If you just want to create a policy for a short-term project (to ensure it is automatically cleaned up when it is not needed), you can create a Site Policy that automatically deletes a site six months after it is created and sends a recurring warning e-mail to the site owners starting three months from the delete date. After that date, the site (and its associated Site Mailbox if there is one) will be deleted automatically by the Expiration Policy timer job unless a site owner manually postpones deletion.
Perhaps you want to put a site collection in read-only mode after a certain time. You can create a Site Policy, for example, that closes a site collection five years after its creation. Upon closure, the site collection can be set to read-only mode. One year following site closure, the entire site collection will be deleted. Once you have created your Site Policy, you can directly apply it to sites by publishing Site Policies from a content type hub to use in all the sites in your farm, or even apply them during site creation time with self-service site creation.
To publish the Site Policies you must first set up Content Type Syndication on a Content Type Hub. Once that is complete, create your Site Policies on the Content Type Hub Site. To the right of your Site Policy list, you’ll see a new Publish Policy column with a link to “Manage publishing for this policy”. Clicking the link will bring you to the publishing page where you can publish (push the Site Policy to all consuming site collections in a read-only state), re-publish (push down changes to previously published Site Policies), or un-publish (leave the published policy on the consuming site collections in an editable state).
If you want users to be able to create their own sites and choose a Site Policy to be applied at creation time, start by setting up Self-Service Site Creation. Once that is done, you can use the Self-Service Site Creation administration page in Central Administration (or Tenant Admin in SharePoint Online under Settings) to choose one of three states for Site Policy: Hidden from users (no Site Policy will be applied), An optional choice (users may apply a Site Policy or none at all), or A required choice (user must choose a Site Policy before the site will be created).
After completing this configuration, users will be presented with a new dialog box on their Self-Service Creation dialog with the published Site Policies available for the site.
If a site is about to be deleted or if the site collection is in read-only mode, an information bar will appear at the top of the site for all users. This way, users can be made aware and have a chance to contact their site administrator in the event they believe the site should not be deleted, be reopened, and so on.
Site Policy also ensures that sites with associated Site Mailboxes are also kept in the same state as the site itself (Closed, Open, or Deleted). Whenever the state of the site changes, a work item is sent to the Site Policy and Exchange Site Mailbox Policy Update Timer Job. By default, this Timer Job will run once per day and update the state of the associated Site Mailbox. There is CSOM (Client Side Object Model) code available to remotely determine the status of the site and change its state. You can find out if the site is closed, apply a Site Policy, manually open the site, and much more. You can also use the Site Policy CSOM to customize the subject and content of the site deletion alert e-mail by inserting the tokens for the site url ("<!--{SiteUrl}-->"), site expiration date ("<!--{SiteDeleteDate}-->"), and (if you have an associated Site Mailbox) the Site Mailbox ("<!--{TeamMailboxID}-->") into the body of the custom e-mail.
Note: To be able to compile and execute the below example on a client machine you will need to install the SharePoint 2013 Client SDK. For more information about the Site Policy class and methods, please see the ProjectPolicy MSDN article.
Example:
using Microsoft.SharePoint.Client;using Microsoft.SharePoint.Client.InformationPolicy;using System;
namespace SitePolicyEmailChanger{ class Program { static void Main(string[] args) { string siteCollectionUrl = ""; string relativeSiteUrl = "";
// Get the site and web info Console.WriteLine("Site Policy E-mail Changer"); Console.WriteLine("Enter the Site Collection URL: "); siteCollectionUrl = Console.ReadLine(); Console.WriteLine("Enter the relative Site URL: "); relativeSiteUrl = Console.ReadLine();
// Return the currently applied Site Policy ClientContext context = new ClientContext(siteCollectionUrl); Site site = context.Site; Web web = site.OpenWeb(relativeSiteUrl); ProjectPolicy policy = ProjectPolicy.GetCurrentlyAppliedProjectPolicyOnWeb(context, web); context.Load(policy, p => p.Name, p => p.Description, p => p.EmailSubject, p => p.EmailBody, p => p.EmailBodyWithTeamMailbox); context.ExecuteQuery();
// Display the current Site Policy properties and pause Console.WriteLine(String.Format("Policy Name is: {0}", policy.Name)); Console.WriteLine(String.Format("Policy Description is: {0}", policy.Description)); Console.WriteLine(String.Format("Policy E-mail Subject is: {0}", policy.EmailSubject)); Console.WriteLine(String.Format("Policy E-mail Body is: {0}", policy.EmailBody)); Console.WriteLine(String.Format("Policy E-mail Body (with Site Mailbox) is: {0}", policy.EmailBodyWithTeamMailbox)); Console.WriteLine(); Console.ReadLine();
// Edit the Site Policy E-mail properties policy.EmailSubject = "Contoso Site Deletion Notice"; policy.EmailBody = "The Contoso site <!--{SiteUrl}--> is set to expire on <!--{SiteDeleteDate}-->. If you have any questions or concerns, please contact your admin."; policy.EmailBodyWithTeamMailbox = "The Contoso site <!--{SiteUrl}--> associated with Site Mailbox <!--{TeamMailboxID}--> is set to expire on <!--{SiteDeleteDate}-->. If you have any questions or concerns, please contact your admin."; policy.SavePolicy(); context.ExecuteQuery();
// Refetch the edited Site Policy from the server policy = ProjectPolicy.GetCurrentlyAppliedProjectPolicyOnWeb(context, web); context.Load(policy, p => p.Name, p => p.Description, p => p.EmailSubject, p => p.EmailBody, p => p.EmailBodyWithTeamMailbox); context.ExecuteQuery();
// Display the new Site Policy properties and pause Console.WriteLine(String.Format("Policy Name is: {0}", policy.Name)); Console.WriteLine(String.Format("Policy Description is: {0}", policy.Description)); Console.WriteLine(String.Format("Policy E-mail Subject is NOW: {0}", policy.EmailSubject)); Console.WriteLine(String.Format("Policy E-mail Body is NOW : {0}", policy.EmailBody)); Console.WriteLine(String.Format("Policy E-mail Body (with Site Mailbox) is NOW: {0}", policy.EmailBodyWithTeamMailbox)); Console.ReadLine(); } }}
Microsoft is getting into the solutions content business. What does this mean? Multiple teams across Microsoft are now focusing all or part of their time on developing and publishing lab-tested, multi-product, end-to-end solution content. For example:
The goal of these teams is to help you solve bigger business problems than could be solved through any of these products individually.
We have some ideas regarding what solutions to get started on but we need your input to find out if these are the right ones and what other ones we should do.
Therefore, we are forming a Solutions Advisory Board (SAB) consisting of customers, Microsoft Most Valuable Professionals (MVPs), and people in various roles inside of Microsoft. The SAB will:
If you would like to participate in the discussion around solutions that use any combination of Microsoft products (such as Windows Server, SharePoint 2013, Exchange 2013, Lync Server 2013, Office 365, System Center, SQL Server, or Windows Azure), we invite you to join this new group.
Please contact us at sab@microsoft.com to join.
We look forward to working with you!
Microsoft Solutions Advisory Board
About a year ago we put out a mobility poster covering the SharePoint space. We’ve just released a follow-up that extends into Exchange 2013, Lync 2013, and Office Web Apps 2013. It’s not an exhaustive list of everything available for devices (Windows Phone, iOS, Android). However, it’s a good end-to-end peek at the Office mobile landscape, both Office 365 and on-premises. Some highlights:
So again it’s a good look into Office mobility, and ideal for ITPro decision makers needing to know more about Microsoft offerings here. You can get or view a copy of the poster at:
At the recent SQL PASS Summit, Mark Russinovich (Technical Fellow in the Cloud and Enterprise Division at Microsoft) presented a session titled Windows Azure Deep Dive, featuring SharePoint. His session is a great primer on using Windows Azure IaaS platform to host a SharePoint farm.
Fast forward to 1:13:00 for a description of this beautiful poster — Windows Azure: Deploy SharePoint with SQL Server AlwaysOn (Zoom image, PDF). This poster also includes logical architecture illustrations for publishing Internet sites using SharePoint Server 2013 in Windows Azure, including making use of Azure AD for customer accounts.
Here are some other resources for learning about running SharePoint in Windows Azure.
Blogs:
Blog and scripts: Automating SharePoint Deployments in Windows Azure using PowerShell
Whitepaper: SharePoint 2013 on Windows Azure Infrastructure Services by David Aiken & Dan Wesley
Channel 9 Video: SharePoint on Windows Azure with Paul Stubbs
Now is a great time to let us know what other types of resources you would like to see.
- Brenda Carter