The following script adds a web part to a page using PowerShell and the Client Side Object Model (SharePoint 2013).
Prior to adding a web part to the page you need to:
Get the XML of the web part – the easiest way is to export the web part and view the XML in Notepad. The XML will need to be stored as a variable in your script.
The basic steps:
Open a connection to the site collection
Get the page
Create the web part definition – using the XML from your exported web part
Add the web part to the page
Check in the page
#### CLIENT CONTEXT INSTANTIATED - $CTX ####
# My previous code (not included) deals with connecting to my Site Collection hosted on Office 365
# URL of page where we want to add the webpart
$serverRelativeUrl = '/sites/tDEV/pages/Contact-Us.aspx'
# Get the page
$oFile = $ctx.get_web().getFileByServerRelativeUrl($serverRelativeUrl)
# Load and print out the Title of the page
# CheckOut the page
# Get the webpart manager
$limitedWebPartManager = $oFile.getLimitedWebPartManager("Shared")
# Import the web part using the web part XML, $wpxml contains the XML from the exported web part
$wpd = $limitedWebPartManager.ImportWebPart($wpxml)
# Using the web part definition we can add the webpart to the page - in the header zone.
$limitedWebPartManager.AddWebPart($wpd.WebPart, "Header", "1")
# Check in the page
I generally try to avoid using item level permissions, but I had a specific scenario where these were needed. Had I been using an on-premise solution I would have built a timer job to manage the permissions, however as Office 365 was being used I decided to build a PowerShell script using the Client Side Object Model – the script is executed every night.
The script iterates through a couple of lists each night a performs a couple of actions: Checks for new items
Based on the list item data, find the column ‘EmployeeId’ and query active directory to find the User Principle Name (UPN) (EmployeID is stored against each user in AD).
If the above action finds a user from AD the script removes all permissions on the list item and sets unique permissions so only the employee and a management group have access to that list item.
The following code snippets assume a connection to SharePoint is open (ClientContext), and the current web is loaded into context.
To find the SharePoint group the following was used:
# Load in list of groups on the current web.
$groups = $web.SiteGroups
# Find the group called HR. Note - using GetGroupByName was not working, therefore I had to iterate through the groups.
foreach($group in $groups)
if($group.Title -eq "hr")
$hrGrp = $group.Id
# Get the group and load into context to be used.
$spGrp = $groups.GetById($hrGrp)
To set item level permission on each list item:
# Get the list by Title and load.
$list = $web.Lists.GetByTitle("MyList")
$listTitle = $list.Title
# Simple query - purely used to ensure all data is returned.
$camlQuery = New-Object microsoft.SharePoint.Client.CamlQuery
$camlQuery.ViewXml = "10000"
# Load in the items.
$collListItem = $list.GetItems($camlQuery)
# Iterate through each item.
foreach ($item in $collListItem)
# reset variable to ensure no false positives.
$upn = $null
$user = $null
$roleAssignment = $null
$continue = $false
# Set a couple of variable, get the user from AD based on employee number.
$recordId = $item.Id
$upn = Get-Upn -eid $item["EmployeeID"]
$continue = $false
if($upn -ne $null)
$continue = $true
Add-LogMessage "ERROR: Missing employee number on record '$recordId' "
# Break inheritance on the list item and remove existing permissons.
# Get the permissions role for 'Read' and 'Edit'.
$reader = $web.RoleDefinitions.GetByName("Read");
$Editor = $web.RoleDefinitions.GetByName("Edit");
# Create a role assignment and apply the 'read' role.
$roleAssignment = New-Object microsoft.SharePoint.Client.RoleDefinitionBindingCollection($ctx)
# Create a role assignment for editors - applying the 'edit' role.
$roleAssignmentEditor = New-Object microsoft.SharePoint.Client.RoleDefinitionBindingCollection($ctx)
# Ensure the user exists on the site level, using EnsureUser.
$user = $ctx.Site.RootWeb.EnsureUser($upn)
# Apply the two permission roles to the list item.
# $user is a SharePoint user.
# spGrp is the HR group returned in the above snippet.
# Update field on the list item to show it has ben processed.
$item["A001"] = "PROCESSED"
# Execute changes.
I had a requirement to configure a mechanism within Office 365 to allow pages on an intranet to expire after a set amount of time. When a page has expired the content owner is alerted and a task is assigned to review the page content.
A number of content types have been designed and each content type can have an information management policy assigned to indicate the retention period.
To configure retention in Office 365:
Create a content type the usual way
Connect to the site using SharePoint Designer and create a workflow. Select the SharePoint 2010 workflow engine as this will allow you to connect the workflow to a content type.
Modify the content type through SharePoint (Site Settings –> Content Types) and select ‘Workflow Settings’
This should allow you to select the workflow created in step 2.
Now the content type is ready, and the workflow is assigned to the content type – we now need to configure the retention policy:
Select ‘Information Management Policies Settings’ from the content type page
Configure a retention policy
Configure the expiration policy
Configure the action to start a workflow and select the workflow created earlier.
Note: After testing in Office 365, we cannot manually start the retention timer job to iterate through the expired items – the timer job runs every Sunday at around 08:30 (in my tenant at least) – makes testing quite difficult, so any testing should be completed in an on-prem environment so the timer job can be manually executed.
In our environment we are using Office 365, we configured ADFS / ADFS Proxies / and Dirsync to manage SSO.
We have constructed smart links to ensure users are automatically signed into SharePoint when using their work laptop and Internet Explorer – if they are using a difference device / browser then they are directed to the corporate login page.
We experienced an issue where customers would be requested to sign into Word / Excel / PowerPoint when opening files directly from SharePoint.
This was resolved my modifying the smart links to contain
Recently came across an issue where there were 3 “David Hendry’s” appearing within people search on SharePoint 2013 / Office 365. So if a user searched for me, they would see 3 ‘identical’ people to choose from.
The accounts were:
* My main domain account * My domain admin account * My cloud admin account
The requirement was to hide cloud admin and domain admin accounts from the search results.
The resolution was to edit the People Search Core Results web part…
I modified the query (shown below) to include the domain name for internal accounts, remove any accounts containing adm_ and onmicrosoft.com.