Tag Archives: SharePoint

Custom Web Part – Save settings to SPList (without jQuery)

Ever wanted to code a JavaScript content editor (script editor) web part that saves settings to a list?   Without jQuery?

The library below “wp-settings.js” does exactly that with native XHR (XML HTTP Request) and nested callback to invoke REST API.   The free standing POJO (Plan Old JavaScript Object) design enables us to package into a web part gallery and use freely across any site without preparation work to ensure jQuery, Angular, or other dependent frameworks are loaded.

Look at the “webpart.html” to see example usage pattern:

  • wpsRead()  Get settings (if any)
  • wpInit()  Local web part initialize
  • wpsWrite()  Save settings (UPDATE/INSERT)


Cheers!  shades_smile



Source Code










SPAuditAPI – Read SharePoint audit logs from JavaScript over REST

Recently I wanted to query Audit data from the web browser client and learned no native REST api was available.   So I created one.   Below is a demonstration video and link to the full source code.

This web API enables us to execute the server object model SPAuditQuery() method from HTTP POST and provide optional filter parameters.   More filters give a narrow match and faster server response.   We want to be specific, even if only a default time range (example – past 30 days) to improve user experience and reduce system load.

Cheers!  shades_smile



Source Code




Context Diagram



Screen Shots





Replace CE / SE Web Part Content PS1

Managing front end code (HTML/JS) embedded within Script and Content Editor Web Parts can be a hassle.   With multiple instances scattered across ASPX pages, web part galleries, and many sites quickly becomes untenable.

The below PowerShell script gives SharePoint admins a new way to search/replace the internal text of CEWP/SEWP web parts within a target site collection.    Updating a URL reference or DNS name can now be done across potentially hundreds  of WP in just a few minutes.

For example, a team site having 1 CEWP and 1 SEWP with the world “hello” can be quickly replaced with “hola” by running this script.

Cheers!  shades_smile


Source Code


Screenshot – Before





Screenshot – After






Simple URL Shortener

Recently I wanted to create a URL shortening service for SharePoint 2013.  Yes, SharePoint 2016 ships with “Durable Links” but many places run older version.   Yes, there are commercial software packages available for sale but management and budget approval can be challenging.

Why not create a simple redirect ASPX with a Custom List of URLs?

Check out the brief video below to see it running live.   The Install PS1 script will create the needed List and upload front end files (ASPX + JS).


Source Code






PowerShell – Create SharePoint Alert remotely (CSOM)

I want to migrate user alerts to Office 365 from SharePoint 2013 on-prem and was surprised to learn there is no client side API for creating Alerts.   Not SOAP, not REST, nothing but the web browser ASPX web form GUI.

So I took Fiddler and inspected the HTTP POST traffic when you click “OK” on the SharePoint “SubNew.aspx” page in the browser.   Lots of great detail!    You can see all the ASPX web form controls and internal values.   Clicking the “OK” button posts that event back to the server side Dot Net for processing with Request Digest, ViewState, and lots of cool stuff.

So …. could we simulate sending that same HTTP traffic?   From somewhere else?    Like PowerShell??    That’d be awesome!


Below is the working concept. PowerShell function with a handful of sample calls. Immediate alert, Daily, Weekly scheduled, etc. With various recipients and filters. Enjoy!  shades_smile










Code  (CreateSPAlert.ps1)

Function CreateSPAlert($webURL, $listID, $userLogin, $userDisplayName, $alertTitle, $changeType, $sendAlertsFor, $whenToSend, $whenToSendDay, $whenToSendTime) {
    ASPNet WebForm Input Values
    -1 All changes
     1 New items are added
     2 Existing items are modified
     4 Items are deleted
    0 'Anything changes'
    1 ''
    2 ''
    3 ''
    0 immediate
    1 daily
    2 weekly
    0 Sunday
    1 Monday
    2 Tuesday
    3 Wednesday
    4 Thursday
    5 Friday
    6 Saturday
    12:00 AM
    1:00 AM
    11:00 AM
    12:00 PM
    1:00 PM
    11:00 PM
    # Convert parameters
    switch ($sendAlertsFor) {
        '1' {$sendAlertsFor=''}
        '2' {$sendAlertsFor=''}
        '3' {$sendAlertsFor=''}
        default {$sendAlertsFor='Anything changes'}
    # List Scope
    $url = "$webURL/_layouts/15/SubNew.aspx?List=$listID"
    $fields = Invoke-WebRequest -Uri $url -UseDefaultCredentials -UseBasicParsing  | select -ExpandProperty inputfields | select name, value
    # HTTP POST Body WeBforms
    $postParams = @{
    '__REQUESTDIGEST' = ($fields|? {$_.Name -eq '__REQUESTDIGEST'}).Value;
    '__VIEWSTATE'=($fields|? {$_.Name -eq '__VIEWSTATE'}).Value;
    '__EVENTVALIDATION'=($fields|? {$_.Name -eq '__EVENTVALIDATION'}).Value;
	# Append if needed
	if ($whenToSendDay) {
	if ($whenToSendTime) {
    # Execute HTTP
    $response = Invoke-WebRequest -Uri $url -WebSession RequestForm -Method POST -Body $postParams -ContentType 'application/x-www-form-urlencoded' -UseBasicParsing
# Main
$start = Get-Date
# Create SP alerts
CreateSPAlert 'http://sharepoint/sites/test' '%7B0D568A08%2DD7AA%2D405B%2DADE1%2DF324216C0272%7D' 'i:0#.w|company\\jsmith' 'John Smith' 'Documents' '-1' 'Anything changes' '0'
CreateSPAlert 'http://sharepoint/sites/test' '%7B0D568A08%2DD7AA%2D405B%2DADE1%2DF324216C0272%7D' 'i:0#.w|company\\jsmith' 'John Smith' 'Documents' '4' 'Anything changes' '0'
CreateSPAlert 'http://sharepoint/sites/test' '%7B0D568A08%2DD7AA%2D405B%2DADE1%2DF324216C0272%7D' 'i:0#.w|company\\jsmith' 'John Smith' 'Daily-Documents' '4' 'Anything changes' '1' '0' '7:00 PM'
CreateSPAlert 'http://sharepoint/sites/test' '%7B0D568A08%2DD7AA%2D405B%2DADE1%2DF324216C0272%7D' 'i:0#.w|company\\jsmith' 'John Smith' 'Weekly-Documents' '4' 'Anything changes' '2' '5' '5:00 PM'
# Run duration
$end = (Get-Date) - $start
$ms = $end.TotalMilliseconds
"$ms MS duration"




Hot NEW download – SharePoint Migration Assessment Tool (SMAT)

Microsoft recently published SMAT (SharePoint Migration Assessment Tool) to scan your on-prem SharePoint 2013/2016 farm and prepare for Office 365 migration by reporting on potential issues.   Below are details on the command line usage and report contents.    Migration Assessment Scan Report provides 28 categories and granular site URL level detail into CSV.    Below are descriptions on each category with workaround and migration impact.

Lots of great detail here!  shades_smile


Download ZIP



Command Line Usage

SMAT.exe [-o] [-t] [-sv] is a command line application with three parameters:

  -o    Output folder to store logs and reports generated by this tool.

        If it already exists, all content will be overwritten.

        Default value is \Log folder in the current directory.

-t    Maximum number of threads to run in parallel. The minimum is 1, the maximum is the total number of processors for the machine.

        Default value is half of the available processors for the machine.

-sv  Skips pre-flight checks.





Migration Assessment Scan



The command line EXE will generate a report (Migration Assessment Scan) which provides detail on several categories of potential SharePoint on-prem to Office365 migration issues.   These are classified into 28 sections:



Migrating SharePoint add-ins (formerly called apps) isn’t supported in the target environment. The site content will be migrated, but the add-ins will not. As a result, once the site is migrated, the add-ins will need to be reinstalled. If you purchased the add-in, you will need to reclaim the license from the add-in store.



The migration tooling does not support migrating alerts. Alerts are created on items, lists, and libraries to notify a user of when content changed. This report provides visibility into the alerts that are currently configured in the source environment. If users would like to be notified of content changes after the migration, they will need to configure the alerts on the new environment.   As a result of alerts not migrating, we provide a lot of raw data associated with the alerts should the need arise to recreate the alerts post migration.



Business Connectivity Services (BCS) was introduced in SharePoint 2010 as an improvement to the Business Data Catalog created for Office SharePoint Server 2007. BCS enables SharePoint to access data from external data systems such as SAP, ERP, and CRM, in addition to other data-driven applications that are exposed through Windows Communication Foundation (WCF) services or Open Data (OData) endpoints.


Browser File Handling

The Browser File Handling settings on the Web Applications in SharePoint impact how you can browse certain file types. The source environment allowed you to change this setting from Strict to Permissive. The Permissive setting enables you to open all file types within the browser. However, in the target environment, the Strict setting is enforced and cannot be modified. As a result, you may find some file types will not open in the browser post migration. For example, *.htm and *.html files in document libraries will no longer open in the browser. Users will be prompted to download the files.

Checked-out files

Migration reads the source SharePoint farm using an account that has Full Read access to the environment. If a file is checked out by a user, the migration tooling is not able to read the checked out file. However, the migration tooling will see the last checked in version of the file instead. To avoid losing data, users should check-in their files prior to their site migrating.

Custom Profile Property Mappings

In the source environment, it was possible to add additional profile property mappings to the User Profile Service Application via a standard change request (CR). The profile property mappings enable SharePoint to pull in profile property values from data sources outside of SharePoint. For example, you could map a profile property to an attribute in Active Directory. During a profile sync, SharePoint populated the user’s profile with the value from Active Directory. Another scenario was to leverage Business Connectivity Services (BCS) to populate profile property values from a database or web service.

The target environment leverages Azure Active Directory (AAD) to populate the SharePoint profile values. SharePoint will synchronize the most common profile data from Azure Active Directory into SharePoint. The target environment does not support extending the AAD schema and configuring additional profile property mappings. If you need to populate data that is not provided by the out of the box profile property mappings, it is required to write a program that will push the values you want into the profile properties in the service. The following article provides guidance on updating profile property values leveraging the Client Side Object Model (CSOM).



Customized Pages

Customized files are out of the box SharePoint files that have been modified by a user. A common example is using a tool like SharePoint Designer to open a site and modify the default.aspx file of a site. During migration, these pages will be reverted to their uncustomized state.

Any file modified by the SharePoint System Account is excluded from the scan report.

Customized Profile Pages

In the source environment, viewing a user’s profile is managed by a page hosted in the My Site Host named Person.aspx. For example, clicking on a colleague’s name in a document library or from their OneDrive for Business will take you to the person.aspx page to view the user’s profile.

Post migration to the target environment, the profile experience is managed by the Delve service. There is currently a limitation in that the Delve profile page cannot be modified. This scan report will show you any customizations that have been made to the Person.aspx page in the source environment. This data can be used to understand any impact with the move to the target environment with regards to the profile experience.

Additional Information link: https://support.office.com/article/How-can-I-find-people-and-information-in-Office-Delve-5b8bffdd-a50a-430a-8570-09b39481887c


Email Enabled Lists

…TBA …


File Versions

Versions have historically impacted the length of a migration for a given site in a linear fashion. The more versions you have, the longer it will take to migrate a given site. On the target platform, versioning is enabled for all lists and libraries and the default configuration is a maximum of 10 versions per item. To align with this default configuration, migrations will bring over the last 10 versions of a given item.

If you have a business reason to keep more than this number of versions and the report indicates you have a large number of versions across your environment, you will need to provide the business justification. The 500GB per week estimate will not hold true for site collections that contain a large number of versions.

Full Trust Components (FTC)

…TBA …


InfoPath enables developers to build custom forms for accepting user input in a variety of locations throughout SharePoint. As part of the migration to the target environment, there are certain aspects of InfoPath forms that are not supported in the target environment.   InfoPath forms (XSN files) will be migrated, but some forms may not function without remediation.

IRM Enabled Lists

IRM settings associated with lists and libraries are not migrated. The following process is required to enable the migration tooling to properly handle IRM protected libraries. This process ensures that the content is transferred and accessible post migration.

  1. Disable IRM on the source and target list.

  2. Migration tooling will copy the files from the source and place them in the target.

  3. Enable IRM on the source and target list.

Large Excel Files

The maximum limit for opening XLSX files in the browser is 10MB in the target environment. This setting is configurable in the source environment which may result in a change in behavior for your users. If you attempt to open a file larger than 10MB from a SharePoint site, it will prompt you to open the file in the Excel client application.

Large List Views

On the source environment it is possible to configure list view throttling so there are a set number of hours per day where the throttle on views is lifted. On the target platform, the stated product list limits is in place continuously (24×7). This may result in some of your list views being throttled. 

The lists and their data will be migrated. However, the list views called out in the scan report may not be viewable post migration without performing remediation.

Large Lists

Lists over 20,000 items have historically caused issues with the migration tooling, making the ability to predict the time it takes to migrate sites that contain a larger list to be problematic. If you have large lists that must be migrated to the new platform please work with your Microsoft migration contact to ensure they are aware of your large list requirements, as attempting to migrate the larger lists will require special care when planning the migration event.

List data is migrated. However, the larger the list the more unpredictable the migration process has proven


Large Sites

Migrations occur in 500GB waves. This enables site owners to validate their sites post migration and allows Microsoft to predict the migration schedule. As a result, the maximum site collection size that is in scope is 500GB.

Sites over 500GB are out of scope for migration due to the impacts this has to predicting a migration schedule and delivery of the migration.


Locked Sites

When a site is configured as “No Access” in SharePoint, the site is inaccessible by both users and the system. As a result, the various pre-migration scans are configured to ignore any site that is configured as “No Access”; aka Locked.

Locked sites cannot be migrated to the target environment, as the migration tooling is unable to read the site contents.


Long OneDrive URLs

When you’re moving a OneDrive site from your source to the target environment, the OneDrive URL will change formats. On the source platform the OneDrive sites are in the format of https://onedrive.contoso.com/personal/domain_user. On the target platform, the Domain_User portion of the URL will change to use the UPN for the user. This will look similar to https://onedrive.contoso.com/personal/user_contoso_com.

The migration of the source content resulting in the long URLs will fail. This will cause migration jobs to fail, which will prolong the migration project unnecessarily.


Master Pages

During migration, the default master page will be set on all sites that are migrated. This ensures that the site will render once the migration is complete as the content migration will not have a dependency on any custom master pages. If you have custom master pages assigned to sites, you will need to set the Master Page property on the new site after the migration has completed.

The custom master page files (*.master) will be migrated to the new platform as long as they are in the Master Page Gallery in the site. However, the setting on the destination site will be set to the default master page. This process ensures the site will render after the migration.


Sandbox Solution



Secure Store

Secure Store Service is a shared service that provides storage and mapping of credentials, such as account names and passwords. It enables you to securely store data that provides credentials required for connecting to external systems and associating those credentials to a specific identity or group of identities.

Secure Store applications are not migrated to the target environment.

Unsupported Site Templates

Every SharePoint site is based on a site template. In the SharePoint source environment, it was possible to create site collections using a variety of default templates as well as templates deployed via Full Trust Code (FTC). However, the only target site collections that are supported for migration are the Team Site and Personal Site templates. The Personal Site Template is used for creating OneDrive for Business sites.

Any site collection that is using a site template other than Team Site or Personal Site will be mapped to a Team Site during migration.

TeamSite (STS#1)

Personal Site (SPSPERS#21)


Web Application Policies

In the source environment, there are discreet web applications for Team, Portal, Partner, and MySite (OneDrive). SharePoint OnPremise allows the use of web application policies to grant or deny blanket-level permissions to entire web applications. These permissions override any permissions set at the site collection, site, list/library, or item level.

The target environment uses a single web application to host all site collections.

We do not currently offer a permission feature that applies uniquely to specific root site names and all child items together.

None of the web application policies are migrated to the target environment.


Workflow Associations 2010 / 2013

The migration tooling is able to migrate the Workflow Definitions from the SharePoint source to the target environment. However, any in progress workflow instances are not migrated. As a result, in progress workflows are reset to appear as if they were never started on the destination.

The result of this will be the loss of all running workflow instances.

To avoid unnecessary workflow restarts it is best to complete in-flight workflows before the migration event when your content is moved to the target environment.

Once the migration to the target environment is complete, users will need to restart any workflows that were still in flight.


Workflow Running Solutions 2010  / 2013

The migration is unable to migrate workflows that are in progress. If a workflow on a site or item is In Progress, it will appear as if the workflow was never started on the item prior to migration. If you have business critical workflows that are in progress prior to migration, it is recommended to finish the workflow prior to migration.

Workflow definitions will migrate, however in progress workflow information will not be migrated.

Communicate with end users that in progress workflows will need to be restarted after migration.

Office 365 – Fast Track Tour

Today at Ignite in Atlanta Microsoft announced plans to expand the Office 365 Fast Track portal https://fasttrack.microsoft.com.   If you haven’t seen this before, take a minute to login and explore.

Fast Track gives us success plans for planning migration, migration assistance, a sandbox to try features, support tickets with Office 365 team, and more.    As features expand this portal will become a key part of any successful migration to Office 365.

Personally I can’t wait to see the “free migration assessment tool for SharePoint Server 2013” when that becomes available.  There is also a “Resources” portal at http://fasttrack.microsoft.com/office/resources/envision with TONS of downloads, PDFs,  Word DOCs, PowerPoint PPTs, and all the communication material needed to help drive change at your organization.  Technology staff can learn available options, help management make decisions, and empower end users.

Cheers!  shades_smile




Download Fast Track Guide (PDF)

Image result for office 365


SharePoint 2013 Migration Offer






Portal Screenshots













Business Case for Minimal Downtime Patching (MDP)

After watching the Zero Downtime Patching (ZDP) TechNet video, I wanted to share my thoughts about when that is helpful and when a simpler approach is needed.   Ultimately we are given options and asked to balance cost with questions such as:

  • What is the cost of outage/downtime?
  • What is our SLA?
  • What hours do users normally work?
  • What is the cost of High Availability redundant farm topology?
  • What is the support effort to maintain HA farms?
  • What is the VM, licensing, and storage cost?
  • Bottom line – Does the cost of outage exceed the cost of HA?   Or vice versa?


What is ZDP?

  • [TechNet] “Zero Down-Time patching doesn’t demand any server downtime while patching a SharePoint Server 2016 farm, but does require that your farm be set up in a Highly Available (HA) configuration (so that SharePoint roles are hosted on more than one server). That way, patching can be done in batches where certain of the redundant servers are taken out of load balancing, patched, replaced, and tested for soundness before the other servers follow through the same process.  During Zero down-time patching, users can add and edit files and use search just as at any other time.”


What is MDP?

  • I would define Minimal Downtime Patching as “Planning an acceptable window of brief downtime to apply system updates as quickly as possible.”     This implies an SLA less than 99.99% and 365/24 hour availability.   Choosing a time window for a brief outage is already done today by most support teams.   A few hours outage might come at zero cost (if zero active users) and is often an attractive choice compared to the complexity of Highly Available (HA) farm design, implementation, and support.  ZDP is a high cost endeavor, appropriate for scenarios with high cost of downtime.   Absent that, we should consider lower cost options where brief downtime is acceptable with little impact.    Compare two costs and choice what is best for your business.



 Zero Down Time
Minimal Down Time
  • HA topology required
  • More complex
  • More server cost
  • VM, storage, license, and support
  • Detailed procedure
  • Not available to users
  • Full outage during Config Wiz


  • 100% available to users
  • Read & write features
  • Supports any topology
  • Brief outage
  • Works on Dev, Test, small farms
  • Simple
  • No additional servers
  • Single PowerShell console


Overall, use the right tool for the job.  There are good scenarios for both options.  Even with ZDP used on large Production farms, we need other suitable options for lower environments like Dev and Test.

Cheers!  shades_smile




MDP PowerShell Script


FIXED – 403 ExecuteQuery CSOM from a SharePoint Server

I came across this error when running CSOM requests to Office 365.   While troubleshooting the CSOM call worked beautifully from “powershell_ise” but not regular “powershell.”  Fiddler monitoring showed the cmdlet making HTTP traffic correctly with login handshake from ISE.    However, the regular “powershell” window did not attempt any login handshake.

Strange?   Definitely.

The root cause was “$profile” loading the Server Object Model (SOM) cmdlets before CSOM DLL were loaded.   Why would that matter?  How could it cause a CSOM issue?   There seems to be a DLL namespace overlap internally between these plugins (SOM, CSOM, SPO) so loading sequence matters.  A lot.

By proactively loading the CSOM DLL in $profile before SOM, everything worked correctly from both ISE and the regular PowerShell console.

Hope this helps!  shades_smile



  1. Run CSOM request in PowerShell
  2. From a SharePoint Server on premise (2013 here)
  3. Which also has Microsoft SharePoint Online (SPO) cmdlets installed (https://www.microsoft.com/en-us/download/details.aspx?id=35588)
  4. See this error
  5. Exception calling “ExecuteQuery” with “0” argument(s):  “The remote server returned an error:  (403) Forbidden.






  1. Open PowerShell and type “notepad $profile”
  2. Ensure below code is present.
  3. NOTE – CSOM must load before SOM (Server Object Model) for requests to execute correctly.   Workaround for an internal Microsoft naming overlap.  Both are probably using the same object somewhere.  Loading CSOM first allows CSOM to reserve the namespace first.


Code [$profile]

#CSOM first
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.Runtime") | Out-Null
Add-PSSnapIn Microsoft.SharePoint.PowerShell



Code [csom-only-test.ps1]

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.Runtime") | Out-Null
$url = "https://tenant.sharepoint.com/sites/team"
$user = "admin@tenant.onmicrosoft.com"
$pass = "password"
$secpw = $pass | ConvertTo-SecureString -AsPlainText -Force
$ctx = New-Object Microsoft.SharePoint.Client.ClientContext($url)
$cred = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($user, $secpw)
$ctx.Credentials = $cred
$site = $ctx.Site
if (!$site.TrimAuditLog) {
    $site.TrimAuditLog = $true
    $site.AuditLogTrimmingRetention = 180

Office 365 – Baby Proof SharePoint

Ever enabled a Site Feature out of curiosity?  I sure have.  Great way to learn, but can make support headaches too.   Confusing menus, extra list instances, extra content types, and more surface area to juggle.

Why not try “Baby Proofing” SharePoint in Office 365 by hiding unwanted features?    Client side JavaScript with JQuery CSS selectors can easily hide interface elements during page load.

IT benefits with standardize governance, reduced support calls, and easier migration.   Business benefits with a simpler easy to navigate menu.  Good for both sides.

Less is more!  Give it a try. shades_smile

PowerShell and JS available on GitHub at https://github.com/spjeff/office365/blob/master/office365-gpo/office365-gpo.js 

PowerShell Enable

# Upload JS to https://tenant.sharepoint.com/SiteAssets/o365-simple-menu.js
.\Activate-JS.ps1 -SiteUrl "https://tenant-public.sharepoint.com" -UserName "username@tenant.onmicrosoft.com" -Password "password"


Screenshot – Before





Screenshot – After




Source Code


Return to Top ▲Return to Top ▲