In SharePoint 2010, the Search Center does not provide a link back to the top-level site in the breadcrumb. This is a hindrance for users to find their way back to the top-level site.

Having a link back to the home page of the top-level site would be especially useful in scenarios like Intranet sites. A link could be provided in the breadcrumb back to the Intranet home page. Here is a quick example to add a link to an Intranet home page on a Search Center:

• Open the root site in the site collection in SharePoint Designer.
• Click Master Pages in the Site Objects left-navigation.
• Create a copy of the minimal.master Master Page, and give it an appropriate file name (ie, Intranet_minimal.master). This will be used to create a customized version of the Master Page for the Search Center.
• Open the new Master Page in SharePoint Designer.
• Find the following line:

<SharePoint:SPLinkButton runat="server" NavigateUrl="~site/" id="onetidProjectPropertyTitle" CssClass="s4-mini-h1-a">

• Before that line, add the following to the page:

<!-- Custom Link to Portal -->
<SharePoint:SPLinkButton runat="server" NavigateUrl="~sitecollection/" id="rootSiteBreadcrumbLink" CssClass="s4-mini-h1-a">
    Intranet Home
</SharePoint:SPLinkButton>

<SharePoint:ClusteredDirectionalImage
    runat="server"
    ImageUrl="/_layouts/images/fgimg.png"
    LTROffsetX=0
    RTLOffsetX=0
    LTROffsetY=607
    RTLOffsetY=618
    LTRWidth=11
    LTRHeight=11
    RTLWidth=11
    RTLHeight=11
    AlternateText=":"
    ClassName="s4-mini-titlesep"/>
<!-- End Custom Link to Portal –>

• The specific section of the Master Page should now look like the following:

• Save the custom Master Page.
• Apply the custom Master Page as the default for the Search Center site.
• If you refresh your Search Center site, you should now see a link to the Intranet Home.

Caveat:

While the link to the top-level site is dynamic (~sitecollection/), this example hard-codes “Intranet Home” in the Search Center Master Page. If the Intranet is renamed, the Master Page would need to be updated to reflect the new name.

In this example, our pretend company has decided it would be beneficial for the culture if employees knew how to better work with and relate to each other as they take on and complete projects. To do this, the company decided to focus on a strengths-based culture, to better allow each person's passions drive them to success. One of the methods used to help employees know their own strengths and the strengths of others was having each individual take the Clifton StrengthFinders assessment, to discover their top five strengths. Knowing employees were going to be taking and completing the assessments, the leaders at the company would like each individual to be able to populate their user profile on SharePoint 2010 with these strengths.

Within SharePoint 2010, the list of strengths were added to a Managed Metadata Term Store, so that the spelling and usage of the strengths would be consistent across all of the user profiles:

The following are the steps that would be used to add a property to each person's user profile so that they could assign terms from the Strengths Term Store, and show them on their individual profile.

Create the User Profile Property

Open SharePoint Central Administration, and access the User Profile Service Application by following these steps:

1. Under Application Management, click Manage service applications
2. Find the desired User Profile Service Application in the list, and click to highlight it
3. Click Manage in the Ribbon

On the following page, under People, click Manage User Properties:

On the Manage User Properties page, click New Property:

In the first section, provide the desired Property Settings. In this example, we will choose the name of "CliftonStrengths", and the Display Name of "Strengths". We will choose a multi-value string, with up to 150 characters. The last field maps the property to the managed terms that were previously created in the Term Store.

For the Sub-type of Profile, make sure the profiles are selected that you would like to display the property on. In this case, we only have the Default Profile:

Under User Description, we will provide a description that will help people understand what the intended purpose of the property is for as they are editing their profile:

For the Policy Settings, we will choose Required for the Policy Setting, and default the visibility to Everyone.

For the Edit Settings section, we need to make sure we allow employees to edit the property's values:

On the Display Settings section, we need to show the property on the user profile page. We also need to allow the property to show up to 5 values before being shortened with an ellipsis. To be able to edit the field, we need to allow the property to be shown on the Edit Details page. We also will allow updates to the property to show in the newsfeed.

After these values are set, click OK to create the new user profile property.

Move to the Desired User Properties Section

As shown in the last step, the new Strengths property will be displayed under a section called "Custom Properties". We want to change this so the property shows in the "Details" section. To do this, click the blue "up" arrow next to the name of the property until it is in the desired section.

Edit the User Profile

The property is now ready to be used on the SharePoint user profiles. Navigate to your profile, and click "Edit My Profile":

Scroll down to the "Details" section, and either type or select the five strengths to be listed on the profile:

Click Save and Close.

Then, on the user profile click the link titled "More Information":

The user profile should then show the "Strengths" property, with the selected strengths for the individual.

For one of my SharePoint 2010 VMs, I wanted to upgrade one of the SQL Server Express Edition instances to SQL Server 2008 R2 Enterprise Edition. Since my VM already had SQL Server 2008 R2 Enterprise Edition installed, I only needed to go through the following steps to upgrade the specific instance.

When reviewing the properties of the instance with SQL Server Management Studio, it showed the Product version as SQL Server Express Edition.

Start the Upgrade Process

• In the Start menu, under Microsoft SQL Server 2008 R2, open the SQL Server Installation Center in the Configuration Tools folder.

• Then, under Installation, click Upgrade from SQL Server 2000, SQL Server 2005 or SQL Server 2008.

Install the Setup Support Files

• You may be prompted to browse for the SQL Server 2008 R2 installation media to install the Setup Support files. In my case, I mounted the ISO.

• Make sure the Setup Support Rules pass before continuing on.

• Run the install.

Upgrade the Express Instance

• After the install is complete, you can now continue with the process to upgrade the Express instance.
• Again, make sure the Setup Support Rules all pass before continuing on.

• The setup should find your existing product key. If not, enter it now.

• Accept the License Terms.

• Next, select the SQL instance to upgrade. In my case, the name of the Express instance was "SHAREPOINT".

• The installer will preselect the features to be upgraded in the instance.

• Verify the Instance ID and root directory, and continue on.

• Verify you have enough drive space, and click Next.

• Decide if you want to turn on error reporting, and click Next.

• Verify the Upgrade Rules all pass before continuing on.

• The installer will provide a summary of the upgrade actions. Click Upgrade.

• After the installer finishing the upgrade, it will provide a confirmation page that the instance was successfully upgraded.

• When reviewing the properties of the SQL instance in the SQL Server Management Studio, it will now show that it has been upgraded to SQL Server Enterprise Edition.

• This provided the opportunity to upgrade SQL Server to the latest SP and Cumulative Update level. These can be downloaded from the Update Center for Microsoft SQL Server.
• After running the updates, you can also see the instance's build version through the SQL Server Management Studio.

• In my case, I upgraded to build 10.50.2806, which is Microsoft SQL Server 2008 R2 Enterprise Edition with Service Pack 1 and Cumulative Update 5.

After these steps, I ran the SharePoint Products Configuration Wizard to bring everything up to date.

A common business process scenario for onboarding a new employee within a company is for Human Resources to notify the IT department of the new employee joining the organization, and then for the IT department to create the Active Directory (AD) account and either notify HR, or wait to provide the information to the new employees themselves.

This type of business process might look like the following:

However, given the option, most businesses would like to see this process streamlined to enable HR to create the Active Directory account themselves, in an easy, pre-defined manner.

The streamlined business process could look like the following:

This can be accomplished without any custom development using Nintex Workflow and Microsoft SharePoint.

Using Nintex Workflow to Enable HR to Create AD Accounts

Using a simple SharePoint list, and a couple of the provided Nintex Workflow actions, you could create a simple form for HR that looks like this that enables HR to create Active Directory accounts for new employees:

Using just these simple pieces of information about the new employee, the “Create AD User” Nintex Workflow action can be configured to do the following:

• Create the Active Directory account
• Assign the account name (SAMAccountName)
• Assign the first name and last name
• Assign the manager
• If provided, assign the work phone #
• Create a generated password
• Force the employee to change their password at the first logon

Many other pieces of information could be easily assigned as well with a few changes to the form and the workflow. The basic configuration screen for the “Create AD User” action essentially looks like the following:

Each of these properties could be preconfigured or populated by fields on the initiating form.

Additional Low-Hanging Fruit to Enhance the Business Process

Additional enhancements that could easily be made using out-of-the-box Nintex Workflow actions include enabling the workflow to:

• Create the new user account “Like” another account (using another employee as a model for assignments)
• Assign the user account as a member of Security Groups
• Creating an Exchange mailbox to provision e-mail for the new employee
• Notify IT and the hiring manager
• Enable Lync / Office Communicator for the employee
• Assign the user account to specific AD Organization Units (OUs) based on Department
• And of course, extend the workflow to include more of the onboarding process…

Learn more about Nintex Workflow 2010.

The amount of time the “New” icon is shown in SharePoint 2010 can be changed at the Web Application level using PowerShell. Below are examples to get or change settings for the icon:

Get the Current Duration to Display the “New” Icon

$webApp = Get-SPWebApplication "http://webAppURL/"
$webApp.DaysToShowNewIndicator

Change the Duration to Display the “New” Icon

# Set to 1 Day
$webApp = Get-SPWebApplication "http://webAppURL/"
$webApp.DaysToShowNewIndicator = 1
$webApp.Update()

Prevent the “New” Icon from Displaying

# Essentially, just set the display duration to 0 days.
$webApp = Get-SPWebApplication "http://webAppURL/"
$webApp.DaysToShowNewIndicator = 0
$webApp.Update()

The scenario is that normal users are unable to see the values assigned to Managed Metadata columns or Enterprise Keywords in Lists or Libraries. However, Site Collection Administrators are able to see the values. If a normal user is promoted to a Site Collection Administrator, they are then able to see the column values.

This behavior is most likely caused by the permissions having been changed on the hidden List “TaxonomyHiddenList.” This List essentially caches managed terms and keywords for fast retrieval, rather than having to also query against the Managed Metadata database(s).

To access the List, point your browser to:

<site collection url>/Lists/TaxonomyHiddenList/

Access the permissions for the List, and add “NT AUTHORITY\Authenticated Users” with Read access. This is the default setting, along with the System Account having Full Control access.

If you test your Lists and Libraries again, normal users should now be able to see the Managed Metadata and Enterprise Keyword values.

A SharePoint 2010 environment had experienced a change in how SharePoint would open PDFs that lived in a Document Library. Previously, when someone clicked on a PDF, it would open right away in the web browser for them to view. Now, when someone clicked on a PDF, they would see the following prompt asking them if they would like to open the document in “Read Only” or “Edit” mode:

This behavior was not acceptable, as it was disruptive for people wanting to quickly access the contents of the PDF documents.

Source of the Change

When we tracked down the source of the change, we realized it was due to following Microsoft’s KB on "SharePoint 2010 - Configuring Adobe PDF iFilter 9 for 64-bit platforms.” In step 3, the article says that you need to add the following line to the DOCICON.XML file in the 14 Hive (/TEMPLATE/XML/):

<Mapping Key="pdf" Value="pdf16.gif" />

This step is so that SharePoint will display the PDF icon in Document Libraries and other pages. However, this line is what caused the prompts to start appearing for end users.

Resolution

To stop the prompts from appearing, we needed to override the implicit OpenControl value from the previous change to the DOCICON.XML. We changed the line to the following:

<Mapping Key="pdf" Value="pdf16.gif" OpenControl="" />

After performing an IISReset, end users were no longer seeing prompts when opening SharePoint hosted PDF documents. The PDFs would open right away in their web browser as before.

I had a scenario where I needed to update the Thesaurus file for a SharePoint Server 2010 install. From what I could tell from the TechNet article on Managing thesaurus files, the file (tsenu.xml – English, United States) should be located in the following directory:

%ProgramFiles%\Microsoft Office Servers\14.0\Data\Applications\<GUID>\Config\

The GUID is supposed to match the GUID of the Search Service Application. However, when I went into the Applications directory, I saw multiple GUID-based folders.

Attempt 1

I went to Central Administration, but I wasn’t seeing a matching GUID when looking at the URLs on the service applications.

Attempt 2

In a SharePoint Management Shell, I tried running Get-SPServiceApplication, however the GUID for the Search Service Application didn’t match any of the folders either.

Attempt 3

In the SharePoint Management Shell, I also tried running Get-SPEnterpriseSearchService, however no luck on the GUIDs there either.

Resolution – Using Process Monitor

I finally decided to brute force the answer. Here are the steps I took to figure out which file SharePoint was looking at:

1. I downloaded and extracted the free Process Monitor utility from Microsoft.
2. I opened the Search Center for a Site Collection.
3. In Process Monitor, I configured it to only watch for file system activity and started logging the activity.
4. I then performed a search in the Search Center.
5. After the search was completed, I stopped Process Monitor.
6. I then saved the log of the file system activity to a CVS file.
7. From within Excel, I filtered the “Path” column to only look for entries that contained the text “tsenu.xml”.
8. I only came up with a single path that matched.
9. I modified the file, entering an example expansion set (see TechNet article).
10. I then restarted the “SharePoint Server Search 14” Windows Service.
11. After the service had restarted, I went back to the Search Center, and was able to successfully search for results based on the expansion set I had put in the thesaurus file.

If you have created multiple managed metadata services, so that you can have multiple global term stores, you may have noticed that keywords entered into the Enterprise Keywords field are stored in only one of the term stores. Depending on your desired information architecture, you may want new keywords to be stored in a different term store rather than the default. This can easily be defined by managing the properties of the managed metadata service connections.

Steps

1) Log in to Central Administration

2) Under Application Management, click Manage Service applications

3) Find the current Managed Metadata Service where Keywords are being stored, and click the entry for the Service Connection below it:

4) In the Ribbon menu, click Properties

5) On the properties page, uncheck This service application is the default storage location for Keywords

6) Click OK

7) Find the desired Managed Metadata Service for Keywords to be stored in, and click the entry for the Service Connection below it:

8) In the Ribbon menu, click Properties

9) On the properties page, check This service application is the default storage location for Keywords

10) Click OK

All of the new Keywords entered in your environment’s folksonomy will now be stored in the new term store.

The Team Project portal site in TFS 2010 is the collaboration hub for many activities that typically includes document libraries, team calendar,  wiki, reporting, and more.  TFS 2010 includes a number of reports that can be displayed on the portal using SSRS (using either SharePoint 2010 Foundation or SharePoint 2010 Enterprise) and Excel Services (using SharePoint 2010 Enterprise).    In this post, I will walk through customizing the report to display the burndown for the particular Iteration..

The first question I often receive is:

How do I customize the burndown dashboard report to fit my Sprint/Iteration?

When you display the project portal page and view the burndown dashboard report, you will notice that the default parameters don’t match the current iteration.  To update this, we can override the parameters being passed into the report through the URL.  I want to set Start Date, End Date, and Iteration parameters to display the correct data.

First, navigate to the page with the report

Click on the arrow and choose “Edit Web Part” to edit the parameters for the report.

On the right of the screen is the settings for the web part and report. The link is what needs to be modified.

http://tfsserver/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2fBP%2fTeamProject%2fDashboards%2f
Burndown&rs:Command=Render&rc:Toolbar=false&StartDateParam=07/05/2011&EndDateParam=07/26/2011

To Determine the properties to add or change, you can go to the report itself and look at the properties available. In this example, we want to update the Start Date and End Date and add the Iteration. To find out what the name of the Iteration parameter is, go to the following URL to see the properties.

http://tfsserver/Reports/Pages/Folder.aspx?ItemPath=%2fTfsReports%2fBP%2fTeamProject%2fDashboards&ViewMode=List

Choose the Manage option in the context menu of the report

In the settings screen, choose the Parameters tab and find the parameter you are looking for. This is the name we will add to the URL above. In this instance, it is IterationParam

The format of the IterationParam parameter wasn’t intuitive.  The item is a multi-select checkbox list.  So it wouldn’t take a simple text value such as “Iteration 01”.

To figure out the format of value, I used the report viewer to set the value of the Iteration and exported the report as an Atom feed.  Then I opened the Atom XML and to pull out the value of the Iteration Param that it created.  Below is what the link looks like with the IterationParam value added.

http://tfsserver/ReportServer/Pages/ReportViewer.aspx?%2fTfsReports%2fBP%2fTeamProject%2fDashboards
%2fBurndown&rs:Command=Render&rc:Toolbar=false&IterationParam=%5BWork%20Item%5D.%5B
Iteration%20Hierarchy%5D.%5BIteration1%5D.%26%5B7130920747760410946%5D%26%5B-4689172157298829814%5D&
StartDateParam=07/06/2011&EndDateParam=07/26/2011

Finally paste this URL into the link in the web part and save. This is ready to display.

Mike Douglas