Thursday, December 31, 2015

SharePoint 2013: Something went wrong. To try again, reload the page and then start the workflow


When users try to manually start a 2013 workflow on a list item, they experience the following error message:
They experience this error message when attempting to start any 2013 workflow.  They do not experience this error message when starting 2010 workflows.


  • Verify that all 2013 workflow services have been started.


  • None


  • When I experienced this error message, I first checked if a simple 2013 workflow would run. When that also failed, I suspected that it was 2013 workflow infrastructure related.  For this farm, all workflow services (aside from the usual client services) ran on a single application server.  To begin troubleshooting, I first checked the status of all 2013 workflow services on the application server.  I then discovered that the Service Bus Message Broker service was stopped.  After starting this service again, and I reloaded the page, and I was able to start 2013 workflows again without issue.  No need to re-publish the workflow.

Monday, December 28, 2015

DocAve 6: svchost (968) A significant portion of the database buffer cache has been written out to the system paging file


You administer a SharePoint 2013 farm.  You have deployed DocAve 6 Manager for SharePoint to a dedicated server to help manage the farm (Windows Server 2012, 8GB RAM). During routine checks, you see the following warning appear in the that server's Application log:
svchost (968) A significant portion of the database buffer cache has been written out to the system paging file.  This may result in severe performance degradation.
See help link for complete details of possible causes.
Resident cache has fallen by 4010 buffers (or 100%) in the last ? seconds.
Current Total Percent Resident: 0% (0 of 4011 buffers)
Reviewing the server Application log, you find that this warning occurs about every few days, sometimes several times in a day.  Checking current memory usage, you find it to be a steady 36%.



  • Increase RAM


  • Virtualized Windows Server 2012.  Static memory.

Wednesday, December 23, 2015

SharePoint 2013: how to build a basic search-driven list


This procedure walks through the steps for building a basic search-driven listing.  The specific case presented here involves a need to present in one site collection a filtered view of a listing in another site collection.  The listing is a service ticket listing, and the filtered view will show only those list rows (i.e., tickets) having specific values for the row's Admin Category and SD Status columns, both of which are type Choice.  The approach presented here involves first building a new search result source, and then configuring a a search results web part to use this result source.



  1. Obtain the target list URL
    1. Navigate to the target list.
    2. Copy the list URL, but leave out the page that will be a part of this URL.  For example, if the URL is ...[MyWebsite]/Lists/[MyList]/MyView.aspx, leave off the MyView.aspx.
  2. Identify the target list columns and their search property mappings
    1. Navigate to the target list.
    2. Note down the names of the columns that you want to filter by.
      In this case, both columns are Choice columns.  That's a good thing because the Search service automatically creates managed properties for these column types.  You need to have managed properties so that you can filter on these properties when you configure the result source.  Having them created automatically by Search means less work for you to go in and create them yourself.
    3. Now go to Central Administration: CA > Search Administration > Search Schema.  The Search Service: Managed Properties page is presented.
    4. In the Managed property Filter box, enter the name of a property and perform a search for this property.  Look in the Property Name column.  You'll find the column name without any spaces between the property names, and this will be concatenated to some other characters.  For example, a Choice column type named Admin Category would then be indexed as AdminCategoryOWSCHCS.  Note the formulation of this property name: you'll see this again and again.  The SD Status column would then be indexed as SDStatusOWSCHCS.  Finding it verifies that Search has found the list column and has automatically created a managed property for it.  That's all you need to do.  Repeat for each other column that you want to filter by.
      Note: if the column is one of these types: Lookup, Calculated, Task outcome, Summary Links data, or Rich media data for publishing, Search will not automatically create a managed property for it and you will need to do this yourself.  Creating a managed property is outside the scope of this procedure.  However, plenty of guidance is offered in the references listed below.
  3. Create a new result source
    1. Navigate to the site collection, in which you want to build the search-drive list.
    2. Go: Settings > Site Settings > Site Collection Administration > Search Result Sources.
    3. Click New Result Source.
    4. Add a name, and then click the Launch Query Builder button.  The Build Your Query popup appears.

      Looking in the Query text box, you only see this:
    5. From the Property filter dropdown, select Path.
    6. Immediately below this dropdown, you'll see two other dropdowns.  The first one has "Contains" selected and the second has "Select value" selected by default. From the second dropdown, select Manual value.  A new text box appears immediately below it.
    7. Into this textbox, paste the URL you copied previously, and then click the Add property filter button.
      Looking in the Query text box, you now see this:
      {searchTerms} Path:http://[MyWebsite]/Lists/[MyList]/
    8. From the Property filter dropdown, select --Show all managed properties--.  This expands the dropdown.  You'll now see listed all of the managed properties.
    9. Scroll through this list until you find the managed list column property.  For example, I would look for AdminCategoryOWSCHCS.  Select this.
    10. Now, make sure that the first dropdown underneath this displays Contains.  From the second dropdown, select Manual value.  When you do that, a textbox will appear underneath this.  Into this text box, enter the appropriate column value. In my case, i wanted to find tickets categorized as Website Update.
    11. Once you enter the appropriate text, click the Add property filter button to update the Query text box.  You'll now see this:
      {searchTerms} Path:http://[MyWebsite]/Lists/[MyList]/ AdminCategoryOWSCHCS:Website update 
    12. Repeat for the next list column that you want to filter on.  For my case, I wanted to filter on the SD Status column, for those tickets having status Engaged.  Adding that property value to the query obtains this:
      {searchTerms} Path:http://[MyWebsite]/Lists/[MyList]/ AdminCategoryOWSCHCS:Website update SDStatusOWSCHCS:Engaged
    13. Click the Test query button to see the results displayed in the Query Builder popup.
    14. Now click OK.  This closes the Query Builder.
    15. Click Save.  This adds the new result source to the list of managed result sources.  Since this result source was created in a site collection, it will only be visible to web parts used on website pages within that site collection.
  4. Add and configure the Search
    1. Navigate to the page on which you want to present the filtered list view.
    2. Click on the gear icon (Settings), and then select Site Settings.
    3. On the page, click on the Add a Web Part link for the desired zone.
    4. On the Categories group, in the ribbon, select Search, then select Search Results from the Parts group, and then click the Add button.  An instance of the Search Results web part appears on the page.
      Don't worry about the extra text that you see in the web part: this appears only while in edit mode. Once you save the page and go back to view mode, this extra text no longer appears.
    5. On the Search Results web part, look on the title bar and you will see a small down arrow. Click this arrow, and then select Edit Web Part.
    6. Now look for the Properties for Search Results configuration box.  On this box, click the Change query button.
    7. On the BASICS tab, look for the Select a query section and the dropdown in this section.  It might have Local SharePoint Results already selected.  Open this dropdown and note all of the result sources that are listed.
      Result sources created at the farm level will have "(service)" next to their names.  Result sources created at the site collection level will have "(site collection)" next to their names.
    8. From this dropdown, select the result source that you created previously.  There is nothing more that needs to be done here as the result source is already configured to retrieve the list items that you want.
    9. Click the Test query button, lower down, and then wait a few seconds.  The desired items will appear in the SEARCH RESULTS PREVIEW pane.
    10. Click OK.  You now have a basic search-driven listing.  


  • Don't confuse "level" here with the scope of the search index that is available for querying. "Level" as used here only involves the visibility of the result source; not the scope of the result source.  For example, a result source created at the site collection level will only be visible to web parts added to website pages within that site collection.  It would not be visible to a web part on a website page in a different site collection.  If you want to make result sources visible to web parts on website pages in all site collections, you must create the result source directly through the search service application itself, which means at the farm level.
  • You don't need to specifically map the list properties (AKA Columns) that are crawled. As noted in Overview of the search schema in SharePoint Server 2013: Managed properties and property mapping,
    Some crawled property types automatically generate a new managed property and a mapping between the crawled and managed property. For example, all site columns from SharePoint libraries have this automatic generation and mapping. When you create a site column in a list, and you crawl that list, a crawled property, a managed property, and a mapping between the crawled and managed property is automatically created for the site column
    Well, not all.  Lookup columns, for example, do not automatically have managed properties created for them.
  • This listing is only as current as the crawl interval.
  • To modify the way in which the results are presented, you will need to create a customized display template.

Tuesday, December 22, 2015

SharePoint 2013: You don't appear to have permission to view the account credentials for this result source


You navigate to the Result Sources page of a site collection (Site Settings > Site Collection Administration > Search Result Sources).  You then click on one of the result sources listed and then observe this error message:
This error message is confusing in that you are logged in using an account that has both farm administration and site collection administrator privileges.  The key terms in this error message that actually point to the solution lie at the end of the third sentence: " that level."
Result sources created at the farm administration level, i.e., through Central Administration, can only be edited at that level.  Result sources created at the farm level will be visible both at that level and at the site collection level.  Result sources created at the site collection level will only be visible and editable at the site collection level.  The level at which a result source is created can be seen on the Result Sources page, which will present somewhat different categorizations depending on whether you are viewing this page through the Search Service (farm level) or site collection settings:
Search Service: Manage Result Sources (farm level)
  • Defined for this search service
  • Provided by SharePoint
 Result Sources (site collection level)
  • Defined for this site collection
  • Provided by the search service
  • Provided by SharePoint


  • If you created the result source through the search service's Manage Result Sources page, navigate back to that page to edit the result source.
  • If you created the result source at the site collection level, navigate to the site collection's Search Result Sources page to edit the result source.


Thursday, December 17, 2015

SharePoint 2013 TIP: how to set a lookup column via PowerShell

I needed to change a choice column to a lookup column and then update the new lookup column with the values of the old choice column. Lookup columns cannot be updated in the same manner as text and choice columns. The lookup column is a different variable type than plain text. Therefore, to set its contents, a variable of the same type must be created explicitly or implicitly, populated, and then pushed into the lookup column.

In this particular example, I needed to make this change for a service ticket tracking list. The old status column was of type Choice, and I needed to change it to type Lookup, so that I could implement basic metrics using the undocumented count related method. The Choice column had four possible values: Initiated, Engaged, Resolved and Closed. These needed to be pushed appropriately into the corresponding new column. There are several approaches presented here. The approach I used involved explicitly creating the variable type needed.


$SourceWebURL = "http://[yourwebsite/yourlist]" $SourceWeb = Get-SPWeb $SourceWebURL $TicketList = $SourceWeb.Lists["[ticketlistname]"] $StatusList = $SourceWeb.Lists["[lookuplistname]"] $StatusListItemInitiated = $StatusList.GetItemById(1); $StatusListItemInitiatedValue = New-Object Microsoft.SharePoint.SPFieldLookupValue($StatusListItemInitiated.ID,$StatusListItemInitiated.ID.ToString()); $StatusListItemEngaged = $StatusList.GetItemById(2); $StatusListItemEngagedValue = New-Object Microsoft.SharePoint.SPFieldLookupValue($StatusListItemEngaged.ID,$StatusListItemEngaged.ID.ToString()); $StatusListItemResolved = $StatusList.GetItemById(3); $StatusListItemResolvedValue = New-Object Microsoft.SharePoint.SPFieldLookupValue($StatusListItemResolved.ID,$StatusListItemResolved.ID.ToString()); $StatusListItemClosed = $StatusList.GetItemById(4); $StatusListItemClosedValue = New-Object Microsoft.SharePoint.SPFieldLookupValue($StatusListItemClosed.ID,$StatusListItemClosed.ID.ToString()); $total=$TicketList.Items.count; $Count=1; ForEach ($Item in $TicketList.Items) { $percent = [math]::Round(($count/$total)*100,2); Write-Progress -Activity 'Updating Ticket listing ' -Status "$percent percent" -PercentComplete $percent; $SDStatus = $Item["SD Status"]; IF ($SDStatus -eq "Initiated") { $Item["SDStatus2"] = $StatusListItemInitiatedValue; $Item.Update(); $count = $count+1; } ELSEIF ($SDStatus -eq "Engaged") { $Item["SDStatus2"] = $StatusListItemEngagedValue; $Item.Update(); $count = $count+1; } ELSEIF ($SDStatus -eq "Resolved") { $Item["SDStatus2"] = $StatusListItemResolvedValue; $Item.Update(); $count = $count+1; } ELSEIF ($SDStatus -eq "Closed") { $Item["SDStatus2"] = $StatusListItemClosedValue; $Item.Update(); $count = $count+1; } }; $SourceWeb.Close()


Tuesday, December 8, 2015

SharePoint Designer 2013: value does not fall within the expected range


In SharePoint Designer 2013, you attempt to detach a page from its Page Layout.  You select the file, check out the file, and then click the Detach from Page Layout button on the ALL FILES ribbon.  You are then presented with the following error prompt:


  1. In SharePoint Designer 2013, check out the page.
  2. Export the page to your workstation.
  3. Open the page in NotePad.
  4. Search for <mso:PublishingPageLayout.
  5. Revise the URL string in this tag so that it points to the proper location.
  6. Save the file.
  7. In SharePoint Designer 2013, import the page to the same folder that you exported the original page from.
  8. Overwrite the file.
  9. Now try detaching from page layout again.


  • This issue involved a page on our staging/development farm.  This farm is periodically updated, via content database, from the production farm.
  • On downloading and opening the page in NotePad, I found that the <mso:PublishingPageLayout tag pointed to a master page that was in the production farm.  On review, this made sense in that this page was simply the product of a content database copy and mount process, from production to staging/development; and while navigational URLs are updated in this process, the data embedded in content pages is probably not updated.  Note this for future content migration operations.