SharePoint 2013 – Call Search REST API from PowerShell Script

Add-Type -AssemblyName System.Web

$sServerPath = “http://<Site URL>”
$sQueryOptions = “selectproperties=’ManagedPropertyName’&clienttype=’ContentSearchRegular’&QueryTemplatePropertiesUrl=’spfile://webroot/queryparametertemplate.xml'”
$sUserName = “user name”
$sPassword =”password”
$sDomain=”domain name”
$WebRMethod=[Microsoft.PowerShell.Commands.WebRequestMethod]::Get

function Get-SPSearchResults
{
param ($keyword,$sUserName,$sPassword, $sDomain, $WebRMethod)
try
{
$spCredentials = New-Object System.Net.NetworkCredential($sUserName,$sPassword,$sDomain)
$enckeyword = [System.Web.HttpUtility]::UrlEncode(“‘$keyword'”)
$url = $sServerPath+”/_api/search/query?querytext=$enckeyword”+”&$sQueryOptions”

$spWebRequest = [System.Net.WebRequest]::Create($url)
$spWebRequest.Credentials = $spCredentials
$spWebRequest.Accept = “application/json;odata=verbose”
$spWebRequest.Method=$WebRMethod
$spWebResponse = $spWebRequest.GetResponse()
$spRequestStream = $spWebResponse.GetResponseStream()
$spReadStream = New-Object System.IO.StreamReader $spRequestStream
$spData=$spReadStream.ReadToEnd()
$results = $spData | ConvertFrom-Json
$results = $results.d.query.PrimaryQueryResult.RelevantResults.Table.Rows.results

for($i=0; $i -le $results.length-1; $i++)
{

$row = $results[$i]

for ($j=0; $j -le $row.Cells.results.length-1; $j++)
{

if ($row.Cells.results[$j].Key -eq ‘Title’)
{
Write-Host $row.Cells.results[$j].Value -ForegroundColor Green
}
}
}
}
catch
{
Write-Host $_.Exception.Message -ForegroundColor Red
}
}

try
{
Get-SPSearchResults -keyword “ca” -sUserName $sUserName -sPassword $sPassword -sDomain $sDomain -WebRMethod $WebRMethod
}
catch
{
Write-Host “Problem in running the REST API. Failed with error : ” + $_.Exception.Message -ForegroundColor Red
}

CustomActions not supported in the new SharePoint Online experience

Summary

CustomActions that deploy script, JSLinks, and additional web parts on the page are currently not supported in the new experience. Environments that require these unsupported features should continue using classic mode for the time being.

Affected Software Versions

This functionality is introduced gradually to organizations that have opted in to the SharePoint Online(SPOL) First Release program. This means that you may not yet see this feature immediately as the change is being pushed by Microsoft User by User.

Fix / Resolution

Microsoft is working on the long term plan for this. It does not mean that Microsoft would not support this in future. Microsoft is looking for few different options around these kind of customizations, but unfortunately plans have not yet been locked, so Microsoft can’t share exact final outcome yet.

Interim Workaround

Document Library Level

Flip the impacted document libraries back to classic mode via Library Settings -> Advanced Settings (or in a more heavy-handed approach to configure the classic mode at the tenant level).

Site Contents Page
Thankfully (for now at least) Microsoft gives us a link in the lower left-hand corner “Return to classic SharePoint” that will revert the experience back to the same old lovable customizable SharePoint experience. Tenant level single switch to turn on the classic mode is not available for Site Contents Page.

References

https://veenstra.me.uk/tag/return-to-classic-sharepoint/

You can see the product group response in this user voice request: https://sharepoint.uservoice.com/forums/329214-sites-and-collaboration/suggestions/13385364-allow-javascript-customization-and-css-branding-th and vote

https://www.yammer.com/itpronetwork/#/Threads/show?threadId=721245585

 

Filter on subdirectories in Google Analytics

Business Requirement

Modify the google Analytics to distinguish SharePoint root site traffic from Team and Sites managed path.

At the overview level where we see users and sessions this traffic is combined.  With separate collections, we can better measure the traffic we are looking to measure at a high level.

Solution

In google analytics we have subdirectory filters, and it’s really flexible with regular expressions.

For example, page path matches regex /legal/

Steps to Configure

  • Create a new in google analytics view

g1

  • Click  Filters on the newly created view
  • Click Add Filter Button
  • Provide a filter name and Select Predefined-Filter – Exclude – traffic to the subdirectories – that begin with – /teams/

g2.png

  • Click Add Filter Button
  • Provide a filter name and Select Predefined-Filter – Exclude – traffic to the subdirectories – that begin with – /sites/

g3.png

Notes:

  1. Do not touch or modify the out of the box All Website Data View
  2. We can create only 25 views in Google Free Account.
  3. This configuration will capture the data from the day when we setup this filter in the new view. To refer the old data, we still need to use the All Website Data view.
  4. Make sure the permissions are configured properly under user management for the new view.

SharePoint Page within Salesforce using IFrame

Recently I got a request to display a plain SharePoint ASPX page stored in SPOL publishing site within Salesforce. When I tried this I came across an error “This content cannot be displayed in a frame”. The reason for this issue is SharePoint prevents cross-domain IFRAMING of pages as a security measure to prevent clickjacking.

Tried to follow the below approach but no luck

http://crmbook.powerobjects.com/system-administration/sharepoint-document-management/beyond-basic-integration/displaying-an-office-365-sharepoint-page-in-iframe/

Since I was framing the ASPX page outside SharePoint I have to include additional two lines of code (refer the first two lines in the below image) on the ASPX page to enable IFRAMING. This solution worked for me. Please feel free to share if you have any other better idea.

AllowIframe

References:

https://msdn.microsoft.com/library/office/fp179925.aspx

https://blogs.msdn.microsoft.com/officeapps/2012/12/12/iframing-sharepoint-hosted-pages-in-apps

 

Site Property Bag Manager

SharePoint Property Bag is a great option to store configurations at different levels of the SharePoint hierarchy outside of the application itself. The same property bag entry can be used in SharePoint Search once it is crawled. Based on the requirement we can decide if we need a property bag item with crawl enabled or not.

In the sample SharePoint Hosted app attached, I have mentioned the list of supported properties as I do not want to modify the OOTB properties. Please use this app as starter kit and leverage the same according to your requirement.

Note

Supported Properties

 

Supported Properties - Choices

 

Grid

Edit Supported Property

Download Code

Enable SharePoint Site Owners to read SharePoint site usage data saved in Google Analytics

Problem

  • Most analytic tools allow the site administrators/business leads to read how their site is being visited/used.
  • Site owners cannot review specific data themselves and they have to reach out to site administrators/business leads.

Solution

  • Build a Custom Web API to interact with Google Analytics and enable users to post queries for analytics data directly from a SharePoint Hosted App.
  • Now site owners don’t have to request information from the site administrators/business leads.
  • Site administrators/business leads don’t have to handle the requests coming from site owners to see their site usage.

arc

 

  • User navigates to the SharePoint hosted app page.
  • The SharePoint hosted app page will pass the requests based on the metric selected by the user to collect information using the custom Web API
  • The Web API will authenticate using a service account/Client ID & Secret, then interacts with Google Analytics API and receive the response from Google Analytics, returns the data back to the SharePoint hosted app page.
  • SharePoint Hosted app page will process the output received from the custom API and present the data to user in a readable way as shown below:

gareport

Disclaimer and confession
This is not a drop in solution and you have to adapt it to suit your needs: your mileage may vary and I actually learned most of what I know on this subject the past few years. I am not following best practices, but this post should get you started.

Isolating RER code logic from Provider Hosted Apps

Problem Statement

Users who have full permission on the SharePoint site can delete the mandatory provider hosted apps developed to handle remote events such as List Added, Item Added, etc.,

If the user removes this app by mistake/intentional then the logic written to handle the remote events will not get executed so it’s an overhead for the governance/monitoring job.

Workaround

Deploy the mandatory apps from app catalog as explained here

Optimal Workaround

rer

  • Remove the RER code from the List Settings App (Samples.RER.App) and configure full tenant permissions so that we can attach the RER to any Web or List across the tenant.
  • Instead of installing the List Settings app (Samples.RER.App) in all the sites, install the app only in App Store site so that we have an app principle (app id and secret) that is trusted in our tenant.
  • Don’t deploy the remote web (Samples.RER.AppWeb) that gets created with the List Settings App project (provider hosted).

         Note: I assume you do not have any functionality written on the remote web that gets created with the List Settings App.

  • Create a web project(Samples.RER.Service) that implements the IRemoteEventService interface. This essentially means it must override the methods ProcessEvent and ProcessOneWayEvent methods. Make sure that your project now has the TokenHelper.cs class also. The clientcontext object is retrieved as an app only access token. This code is different from the code that is used normally for a RER.
  • Go back to our web project(Samples.RER.Service) and plug in the App id and secret for the List Settings App in the web.config file.
  • Deploy the app web project(Samples.RER.Service) to azure.
  • Use PowerShell/C# to add/remove receivers to different sites and for different events.
  • When the event occurs, SharePoint will reach out to the WCF Service URL with the event properties object (SPRemoteEventProperties).

The advantage with this setup is that you can keep updating your web project(Samples.RER.Service) and deploy to Azure and then use PowerShell/C# to add/remove receivers to different sites and for different events. There is no need to deploy, remove, redeployment of the app to attach the receivers.

Thank you Srinivas(MS PFE) for this idea.

Follow

Get every new post delivered to your Inbox.

Join 27 other followers