Friday, March 29, 2013

SharePoint 2013: Office Web Apps Issue - We Can't Open This Document - Resolved

I was building out my production environment and configured Office Web Apps as I have done in the past. However, I was receiving an error when attempting to preview search results:

 
 
Sorry, there was a problem and we can't open this document.

Apparently, since I was using HTTP, I needed to perform one more step on the SharePoint 2013 farm. I needed to allow OAuth via HTTP using the following commands:

$config = (Get-SPSecurityTokenServiceConfig)
$config.AllowOAuthOverHttp = $true
$config.Update()



I found this answer in a forum who received the information from here.

I did not have to do this previously when I built my stage environment but I may have been using the SharePoint 2013 Preview version. Now I am using the RTM/Released Version.

I updated my original post to include this step.

 

Monday, March 25, 2013

SharePoint 2013 Search: Fixing an Orphaned Search Component

Problem/Scenario
You previously moved a search component (e.g. Query Processing Component) to a web front end (WFE). For other issue resolutions, you needed to disconnect and then reconnect the WFE server to the SharePoint Farm. In reviewing the current Search Topology, there is an issue with the Query Processing Component:


Resolution

Run PowerShell as Administrator and load the SharePoint snap-in
(or run SharePoint 2013 Management Shell as Administrator):

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

Get the Search Service Application and clone the search topology:

# Clone the active search topology
$ssa = Get-SPEnterpriseSearchServiceApplication
$active = Get-SPEnterpriseSearchTopology -SearchApplication $ssa -Active
$clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone –SearchTopology $active


Issue the following to review the cloned topology:

Get-SPEnterpriseSearchComponent -SearchTopology $clone

Locate the search component (e.g. QueryProcessingComponent) entry with the missing ServerName and copy the ComponentId:


 
 
Remove the component by using the ComponentId above as the -Identity value in the following:
# Remove Orphaned Component
Remove-SPEnterpriseSearchComponent -Identity d8450c12-09a8-4aa4-b824-b709a7a852e0 -SearchTopology $clone -confirm:$false
 
 
Add a new search component component using the respective cmdlet:
# Add New Search Component
$wfe = Get-SPEnterpriseSearchServiceInstance -Identity "<<wfe name here>>"
New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $clone -SearchServiceInstance $wfe
 
 
Activate the search topology:
# Activate  Search Topology
Set-SPEnterpriseSearchTopology -Identity $clone
 
 
That's it! Refresh the search service application page and life is back to good:


SharePoint 2013 Management Shell Cannot load Snap-In Issue Resolved

On a brand new production server after installing and configuring SharePoint 2013, running the SharePoint 2013 Management Shell produced an alarming error:

Add-PsSnapin : Cannot load Windows PowerShell Snap-In
Microsoft.SharePoint.PowerShell because of the following error: Unable to cast
object of type 'Microsoft.SharePoint.PowerShell.SPCmdletSnapIn' to type
'System.Management.Automation.CustomPSSnapIn'.
At C:\Program Files\Common Files\Microsoft Shared\Web Server
Extensions\15\CONFIG\POWERSHELL\Registration\SharePoint.ps1:3 char:1
+ Add-PsSnapin Microsoft.SharePoint.PowerShell
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (Microsoft.SharePoint.PowerShell:St
   ring) [Add-PSSnapin], PSSnapInException
    + FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.Ad
   dPSSnapinCommand


I searched the web for an answer and found some posts in forums. Essentially their answer was to rebuild the server because they installed and reinstalled software and/or upgraded the operating system. In my case, this was brand new - there was no way this was because of an upgrade or software being installed incorrectly.

After trying to repair SharePoint 2013, running the Products Configuration Wizard, uninstalling/reinstalling SharePoint 2013, removing server roles, adding server roles, etc. etc. etc., I finally took a step back and figured out the problem.

I thought this must be an issue with PowerShell and not SharePoint - it turns out it was. To resolve this issue, all you need to do is uninstall and reinstall the Windows Management Framework 3.0.

Simply open the Control Panel on your server and click on programs:

 
On the Programs screen, click View installed updates:

 
Locate Microsoft Windows Management Framework 3.0 (KB2506143), right click the entry, and select Uninstall:


 

Run through the uninstall, restarting the server if directed.

Next, open browser and navigate to the WMF 3.0 download in the Microsoft Download Center. Download and reinstall Windows6.1-KB2506143-x64.msu:



Restart the server if directed. Run SharePoint 2013 Management Shell and the issue is resolved!!!


Friday, March 22, 2013

SharePoint 2013 Search: Error Adding New Search Navigation Link

Search navigation links are the main links within your search center and link to respective search result pages:


You configure these links within the Search Settings page of the site:

 
 
 You can create a new link simply by clicking on the Add Link... link:

Enter at least a Title and URL and click OK.

 
This is pretty simple. I added a few new links but when I clicked on the OK on the settings page, something went wrong:
 
 

 
I could not understand why I was getting the error for a few minutes. The reason is because, apparently, there are some rules behind the link that you provide in the URL of the navigation link:
 
a) the page must actually exist and
b) it must have at least one major version.


Once I actually created my results pages, checked them in, and published a major version, everything worked. So much for trying to put in place holders.



 

SharePoint 2013 Search: Forcing Focus on the Search Box

As a user navigates through your SharePoint Search Center, the page does not focus on any particular control or item on the page:

 
In order to enter or change the search words, the user must click within the search box first. However, I stumbled upon a setting within the Search Box web part (also exists in the People Search Box web part) that will make the search box have focus when the page is loaded. Ironically, the settings is called "Make the search box have focus when the page is loaded".
 
To enable this feature, edit a search results page that contains a search box. From the Search Box drop-down select Edit Web Part:
 

 
 
In the Search Box Web Part properties tool pane, scroll down and expand the Settings section. At the bottom of the section you'll see the option:
 


Simply check the checkbox and click OK. Check in and publish your results page. Now when the page is rendered, the focus is on the Search Box and the cursor appears accordingly.Sometimes the smallest things are the coolest!

 

Wednesday, March 20, 2013

SharePoint 2013: Moving a Site Collection to Its Own Content DB

I wanted to move a site collection to its own content DB and not have any other site collections added. This was for migration purposes but eventually the new content DB will be used for other sites.

The first step to create a new empty content database. Therefore from Central Admin, under Application Management, select Manage content databases in the Databases section:



On the Content Databases page, click on the Add a content database link:
 
 
 
 
On the New Content Database page, enter the new database name and click OK:





Back on the Content Databases screen, click the link of the new content database you created. The Manage Content Database Settings page appears. Change the Database status to Offline:
 
This is such that nobody can add new site collections and have them stored in your new content database. Click OK.

Next, on the server, open SharePoint 2013 Management Shell and issue the following statement:

          Move-SPSite <<http://server/sites/SiteCollection>> -DestinationDatabase <<NewContentDBName>>



 
Run IISReset per the message.
 
Refresh your Content Databases screen and you should see 1 site collection in your new content database, and 1 less in the original content database:




 

SharePoint 2013: Adding People to Everything Search Results

Once again, the main search results, which is now called Everything, does not include People search results. So it's not really everything. The reason is because there is a special People Search Results web part that is catered towards the User Profiles and their respective properties. If I searched for my last name, my personal profile result does not appear:

 
It's all good. With the the SharePoint Search capabilities, you can add some people results into my main search (Everything). First go to the site settings of your Search Center and under Site Collection Administration click on Search Query Rules:
 
 Select Local SharePoint Results (System) in the Context drop-down:
 
 
Once that is selected, click on New Query Rule:

 
On the Add Query Rule page, add a rule name, remove the condition, and then click on the Add Result Block link:
 

 
 
On the Add Result Block page change the Title to state "People Results". In the Select this Source, select Local People Results (System) and select the amount of items. The default is 2 and that's probably not enough (just like beer or martinis). 3 or 5 seem like good numbers.


Under the Settings section, as shown above, select the "More" link option and enter "peopleresults.aspx?k={subjectTerms}". Select People Item from the Item Display Template. Click OK.


Back on the Add Query Rule page, click Save.

Run your search again (it may take a moment for the changes to appear):

The People Results were modified in the above screen shot to protect real people information.


Now I have people results appearing in the search results under Everything!!!


 

Tuesday, March 19, 2013

SharePoint 2013: This Page Has Been Declared a Record

During some development and modifications in our staging environment, we would randomly see status messages when attempting to edit pages: "This page has been declared a record or placed on hold and is locked as read-only.".

Initially I didn't understand where this was coming from. It occured on our home page and this morning it occurred on one of my search results pages. However, in my search center I received an error message as well:

 
 
So I checked the Site Contents and looked at the Pages library:

 
I noticed my pages were checked out by the System Account. So I logged in as the System Account and checked the changes back in. That fixed the error message. Thinking back to the home page issue, the Master Page and Page Layouts were checked out by the System Account as well. So apparently when the System Account edits pages and has them checked out, instead of it stating that another user has the page checked out, it displays this more dramatic status message.
 
 

 

Monday, March 18, 2013

SharePoint 2013: Tweaking the Health Analyzer Rule Definitions

While playing in SharePoint Central Administration in 2010 or 2013, you have probably seen warnings in regards to Health Analyzer issues:


These are most likely ignored in development and staging environments, but what about production?

In production I don't want to ignore these issues but at the same time I don't want to be warned on some things that I don't need to worry about. To tweak how the health analyzer processes these issues all you need to do is modify the rule definitions.

To modify the rule definitions, select Site Contents from the settings menu (gear) in Central Admin. Locate the Health Analyzer Rule Definitions library:



Open the library and select a rule you wish to modify:

 
 
Click Edit Item from the top ribbon:


You may now modify the scope, schedule, enabled, and repair automatically properties:
 
 
Here are some tweaks I have made which may go against best practices but I will explain:



First, I disabled two account rules. The reason is because some of our service accounts are used for application pools and farm accounts and may have admin privledges. It is not the recommended service account structure but it is what it is and I don't need to be notified that this is an issue.



Next I disabled the Drives are at risk of running out of free space. Why? There is already a rule that warns of drives actually running out of disk space. I don't need to be warned about the risk. This alert was occuring against the C: drive of our servers however there is plenty of free space and since we keep our logs on E:, there shouldn't be any worry. The threshold here deals with the amount of memory on the server and having enough room for logs and memory dump files. I think we are safe.

Finally, I changed the Database has large amounts of unused space to run Daily. I want this to be resolved on a daily basis and not have to wait for a week to realize some shrinking needs to occur (or have the amount of unused space grow even larger). I also modified this definition to repair automatically. This will shrink the database as needed.

 

SharePoint 2013 Search: Managed Property Added to Display Template Doesn't Appear

The Search Display Templates in SharePoint 2013 provide a nice and easy way to modify how search results appear to the end user. This may involve adding additional managed properties to the mark-up such that the display template shows additional fields of search data.

However, just adding the managed property to the display template does not automatically bring it into the search results. After making changes to your display template, you may need to update the corresponding result type. This is an easy process.

Go to your site collection settings and under Site Collection Administration click on Search Result Types:

 
On the Manage Result Types page, you'll see a Property Sync message:


This is easily overlooked as it appears similiar to the health analyzer message. Simply click the Update link in the message box. The result types are updated with your display template changes:



Your new managed properties should now flow through into the search results!