Sharepoint 2013 Cumulative Updates Patching Overview

A couple months ago, I had the opportunity to help a client to patch their Sharepoint on-premise 2013, which was last patched up to 2014. It was a challenging but interesting experience. We decided to use the Nth-1 patch, which was March 2018 at that time. It was a 5-weeks engagements, where we had to break down the steps and processes from back-up preparations, roll back strategies, on-patching strategies to post-patching testings. Lots of inputs and discussions among DBAs, system engineers, IT manager and Sharepoint engineers. After all, it was a worthwhile experience as we all learnt a lot from it. Here’ i am breaking down the summary in what we have done.

First of all, we need to lay out the path from early stage to implementation and completion. The high level steps are as:

Inventory check on Sharepoint sites

It is very important to do an inventory check through the existing sites. Do a breakdown list of major sites and their owners, find out which are the most used sites, find out about the amount of storage being used, find out how many custom farm solutions there are.

Test through all aspects of Sharepoint

Application level and backend (central admin) level – We need to be confident with the existing functionalities in Sharepoint, whether they are out of box or custom. Testings need to be done before anything, this is to ensure what you test after the patching still work the same way as before patching.

I would also recommend backing up the existing search service application, just in case it gone corrupted after patching. Remember, anything can happen with the patching, regardless of whether it worked on DEV or TEST farms as each farm configurations can have different configurations and settings.

I would also suggest taking lots of screenshots in Central Admin so that you have a record of existing settings and configurations to compare at later stage.

Backup content databases

Liaise with DBAs to perform backups for content databases. This will likely to take overnight depending on the sizes of your farm and tool being used. Should it have completed successfully, we need to liaise with the system engineer to perform snapshots on all VMs. This should take less time than the content databases backup, however all VMs need to be shutdown prior.

The important thing to note is, we are trying to capture the current state of the farm, so any mis-sync between the VMs or databases would result in a corrupted farm.

Stopping all Sharepoint services

It is important to stop these critical Sharepoint services: IISAdmin, SPTimerV4 and Search. There is Powershell script that can do this but you could also stop them in local server’s Services window.

Applying CU patches

Always login using the farm account on each server.

The order of applying Sharepoint patch is critical. The order we chose to apply was as follow:

  • Front end servers
  • Backend servers
  • Search servers

You can run the patch asynchronously on all server as it doesn’t interfere with each other. The patch only updates the local file system, it doesn’t update the database just yet. Each patch should take no longer than half an hour to complete. Upon completion, restart the server.

Run PSConfig.exe

This must be run in order for the patching process to complete, or else the server status page in Central Admin will not show the updates being applied! I recommend using the command line version rather than the GUI version as we found the GUI version likes to hide error messages and just shows a completion message.

The command we used was this:

PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

The order of running this is also critical. We ran it on App servers first, then front end servers and lastly search servers. Always check on the results, any error or issue would likely be reported here. You need to fix all issues and re-run the command until a success message is shown.

If the patch has been applied successfully, Central Admin -> Upgrade and Migration -> Check product and patch installation status page would immediately reflect the update. Also, check the database configuration version reflects the right new version number.

Note, one issue we had to fix was the removal of orphan features found in various sites. There were a number of these orphan features which was reported by the tool and we used Powershell script to manually remove one by one.

Post-patching testing

Once all patches have been applied, ensure all servers are back up running. Check all the major services are running (i.e. Central Admin, IIS, Search, etc). This is when snapshots from your pre-testing come handy if you can’t remember what services should be running on what server. There are also ULS logs which you could check and scan through to see if there’s any critical issues found.

Then we started with post-patching testings. This should be the same test plans as the pre-testing and the result should match as well.

Some useful links for reference:

 

 

 

Planning Site structure and Navigation in SharePoint Modern Experience Communication and Team sites

If you are planning to implement or implementing Modern team sites or Communication sites, there is change in best practices for planning and managing the Sites structure, Site Hierarchy and Navigation. This is a very common question during my presentations – how do we manage site structures, navigation and content in Modern experiences.

So, in this blog, we will look at few strategies for planning Site structure and Navigation in Modern Experience sites.

1. First and foremost, get rid of nested subsites and Site hierarchy navigation. Recently Microsoft has been pushing for Site Collections flat structure with Modern Team and Communication sites, which adds a lot of benefit for managing isolation and content. So, the new approach – Flat Site Collections and no Subsites. (There are various advantages of flat structure site collections which will be listed in another upcoming blog)

2. Secondly, to achieve a hierarchy relationship among sites such as Navigation, news items, search etc, use Hub Sites. Hub sites are the new way of connecting SharePoint site collections together. Besides, they have added advantage of aggregating information such as News and Search results from related hub associated sites. So, create a Hub site for Navigation across related sites.HubSiteAssociatedTeam

3. A best candidate for Hub sites, in my opinion, is Communication sites. Communication sites have a top navigation that can be easily extended for Hub sites. They are perfect for publishing information and showing aggregrated content. However, it also depends on if the Hub site is meant for a team and business unit or company as a whole. So, use Communication as a Hub site if targeting all company or a major group.QuickLaunchNestedCommunicationSite

4. One Navigation structure – Quick launch (Left hand) is Top Navigation for Communication sites. So no need to maintain two navigations. If you ask me, this a big win and removes a lot of confusion for end users.QuickLaunchEdit_CommSite

5. Quick launch for Modern Team and Communication Sites allows three level sub hierarchy which allows to define a nested custom hierarchy structure for Navigation which could be different from the content structure and site structure.

6. Focus on Content, not on Navigation or location of Content, through new Modern web parts such as Highlighted content, Quick links etc. which allow you to find content anywhere easily.HighlightedContent

7. Finally, few limitations of Modern Site Structure and Navigation (as of June 2018) for reference. Hopefully, this will be changed soon.

    • Permissions management still needs to be managed at each Site Collection, no nested structure there yet. Yet it is possible to use AD groups for consistent permissions set up
    • Office 365 Unified Security Groups cannot have AD or other Office 365 groups nested for Modern Team sites. But SharePoint site permissions could be managed through AD groups
    • Contextual Navigation bolding is missing in Hub sites i.e. if you click on the link to move to a child site then navigation is not automatically bolded, but this might be coming soon.
    • Navigation headers in Modern sites cannot be blank and needs to be set to a link

Conclusion:

Hence in this blog, we looked at an approach for Modern site structures, hierarchy and navigation.

Automate network share migrations to Sharepoint Online using ShareGate PowerShell

Sharegate supports PowerShell scripting which can be used to automate and schedule migrations. In this post, I am going to demonstrate an example of end to end automation to migrate network Shares to SharePoint Online. The process effectively reduces the task of executing migrations to “just flicking a switch”.

Pre-Migration

The following pre-migration activities were conducted before the actual migration:

  1. Analysis of Network Shares
  2. Discussions with stakeholders from different business units to identify content needs
  3. Pilot migrations to identify average throughput capability of migration environment
  4. Identification of acceptable data filtration criteria, and prepare Sharegate migration template files based on business requirements
  5. Derive a migration plan from above steps

Migration Automation flow

The diagram represents a high-level flow of the process:

 

The migration automation was implemented to execute the following steps:

  1. Migration team indicates that migration(s) are ready to be initiated by updating the list item(s) in the SharePoint list
  2. Updated item(s) are detected by a PowerShell script polling the SharePoint list
  3. The list item data is downloaded as a CSV file. It is one CSV file per list item. The list item status is updated to “started”, so that it would not be read again
  4. The CSV file(s) are picked up by another migration PowerShell script to initiate migration using Sharegate
  5. The required migration template is selected based on the options specified in the migration list item / csv to create a migration package
  6. The prepared migration task is queued for migration with Sharegate, and migration is executed
  7. Information mails are “queued” to be dispatched to migration team
  8. Emails are sent out to the recipients
  9. The migration reports are extracted out as CSV and stored at a network location.

Environment Setup

Software Components

The following software components were utilized for the implementing the automation:

  1. SharePoint Online Management shell
  2. SharePoint PnP PowerShell
  3. Sharegate migration Tool

Environment considerations

Master and Migration terminals hosted as Virtual machines – Each terminal is a windows 10 virtual machine. The use of virtual machines provides following advantages over using desktops:

  • VMs are generally deployed directly in datacenters, hence, near the data source.
  • Are available all the time and are not affected by power outages or manual shutdowns
  • Can be easily scaled up or down based on the project requirements
  • Benefit from having better internet connectivity and separate internet routing can be drawn up based on requirements

Single Master Terminal – A single master terminal is useful to centrally manage all other migration terminals. Using a single master terminal offers following advantages:

  • Single point of entry to migration process
  • Acts as central store for scripts, templates, aggregated reports
  • Acts as a single agent to execute non-sequential tasks such as sending out communication mails

Multiple Migration terminals – It would be optimal to initiate parallel migrations and use multiple machines (terminals) to expedite overall throughput by parallel runs in an available migration window (generally non-business hours).  Sharegate has option to use either 1 or 5 licenses at once during migration. We utilized 5 ShareGate licenses on 5 separate migration terminals.

PowerShell Remoting – Using PowerShell remoting allows opening remote PowerShell sessions to other windows machines. This will allow the migration team to control and manage migrations using just one terminal (Master Terminal) and simplify monitoring of simultaneous migration tasks. More information about PowerShell remoting can be found here.

PowerShell execution policy – The scripts running on migration terminals will be stored at a network location in Master Terminal. This will allow changing / updating scripts on the fly without copying the script over to other migration terminals. The script execution policy of the PowerShell window will need to be set as “Bypass” to allow execution of scripts stored in network location (for quick reference, the command is “Set-ExecutionPolicy -ExecutionPolicy Bypass”.

Windows Scheduled Tasks – The PowerShell scripts are scheduled as tasks through Windows Task schedulers and these tasks could be managed remotely using scripts running on the migration terminals. The scripts are stored at a network location in master terminal.

Basic task in a windows scheduler

PowerShell script file configured to run as a Task

Hardware specifications

Master terminal (Manage migrations)

  • 2 cores, 4 GB RAM, 100 GB HDD
  • Used for managing scripts execution tasks on other terminals (start, stop, disable, enable)
  • Used for centrally storing all scripts and ShareGate property mapping and migration templates
  • Used for Initiating mails (configured as basic tasks in task scheduler)
  • Used for detecting and downloading migration configuration of tasks ready to be initiated (configured as basic tasks in task scheduler)
  • Windows 10 virtual machine installed with the required software.
  • Script execution policy set as “Bypass”

Migration terminals (Execute migrations)

  • 8 cores, 16 GB RAM, 100 GB HDD
  • Used for processing migration tasks (configured as basic tasks in windows task scheduler)
  • Multiple migration terminals may be set up based on the available Sharegate licenses
  • Windows 10 Virtual machines each installed with the required software.
  • Activated Sharegate license on each of the migration terminals
  • PowerShell remoting needs to be enabled
  • Script execution policy set as “Bypass”

Migration Process

Initiate queueing of Migrations

Before migration, migration team must perform manual pre – migration tasks (if any as defined by the migration process as defined and agreed with stake holders). Some of the pre-migration tasks / checks may be:

  • Inform other teams about a possible network surge
  • Confirming if another activity is consuming bandwith (scheduled updates)
  • Inform the impacted business users about the migration – this would be generally set up as the communication plan
  • Freezing the source data store as “read-only”

A list was created on a SharePoint online site to enable users to indicate that the migration is ready to be processed. The updates in this list shall trigger the actual migration downstream. The migration plan is pre-populated in this list as a part of migration planning phase. The migration team can then update one of the fields (ReadyToMigrate in this case) to initiate the migration. Migration status is also updated back to this list by the automation process or skip a planned migration (if so desired).

The list provides as a single point of entry to initiate and monitor migrations. In other words, we are abstracting out migration processing with this list and can be an effective tool for migration and communication teams.

The list was created with the following columns:

  • Source => Network Share root path
  • Destination site => https://yourteanant.sharepoint.com/sites/<Sitename>
  • Destination Library => Destination library on the site
  • Ready to migrate => Indicates that the migration is ready to be triggered
  • Migrate all data => Indicate if all data from the source is to be migrated (default is No). Only filtered data based on the predefined options will be migrated. (more on filtered options can be found here)
  • Started => updated by automation when the migration package has been downloaded
  • Migrated => updated by automation after migration completion
  • Terminal Name => updated by automation specifying the terminal being used to migrate the task

 

Migration configuration list

 

After the migration team is ready to initiate the migration, the field “ReadyToMigrate” for the migration item in the SharePoint list is updated to “Yes”.


“Flicking the switch”

 

Script to create the migration configuration list

The script below creres the source list in sharepoint online.

Script to store credentials

The file stores the credentials and can be used subsequent scripts.

Queuing the migration tasks

A PowerShell script is executed to poll the migration configuration list in SharePoint at regular intervals to determine if a migration task is ready to be initiated. The available migration configurations are then downloaded as CSV files, one item / file and stored in a migration packages folder on the master terminal. Each CSV file maps to one migration task to be executed by a migration terminal and ensures that the same migration task is not executed by more than one terminal. It is important that this script runs on a single terminal to ensure only one migration is executed for one source item.

 

 

Execute Migration

The downloaded migration configuration CSV files are detected by migration script tasks executing on each of the migration terminals. Based on the specified source, destination and migration options the following tasks are executed:

  1. Reads the item from configuration list to retrieve updated data based on item ID
  2. Verify Source. Additionally, sends a failure mail if source is invalid or not available
  3. Revalidates if a migration is already initiated by another terminal
  4. Updates the “TerminalName” field in the SharePoint list to indicate an initiated migration
  5. Checks if the destination site is created. Creates if not already available
  6. Checks if the destination library is created. Creates if not already available
  7. Triggers an information mail informing migration start
  8. Loads the required configurations based on the required migration outcome. The migration configurations specify migration options such as cut over dates, source data filters, security and metadata. More about this can be found here.
  9. Initiates the migration task
  10. Extracts the migration report and stores as CSV
  11. Extracts the secondary migration report as CSV to derive paths of all files successfully migrated. These CSV can be read by an optional downstream process.
  12. Triggers an information mail informing migration is completed
  13. Checks for another queued migration to repeat the procedure.

The automatioin script is given below –

 


Additional Scripts

Send Mails

The script triggers emails to required recipients.

This script polls a folder:   ‘\masterterminal\c$\AutomatedMigrationData\mails\input’ to check any files to be send out as emails. The csv files sepcify subject and body to be send out as emails to recipients configured in the script. Processed CSV files are moved to final folder.

 

Manage migration tasks (scheduled tasks)

The PowerShell script utilizes PowerShell remoting to manage windows Task scheduler tasks configured on other terminals.

 


Conclusion

The migration automation process as described above helps in automating the migration project and reduces manual overhead during the migration. Since the scripts utilize pre-configured migration options / templates, the outcome is consistent with the plan. Controlling and monitoring migration tasks utilizing a SharePoint list introduces transparency in the system and abstracts the migration complexity. Business stakeholders can review migration status easily from the SharePoint list and this ensures an effective communication channel. Automated mails informing about migration status provide additional information about the migration. The migration tasks are executed in parallel across multiple migration machines which aids in a better utilization of available migration window.

 

 

Utilizing Sharegate migration Templates for Network share migrations

Sharegate supports PowerShell based scripting which can be used to automate and schedule migrations. The purpose of this post is to demonstrate the use of pre-created migration templates to initiate migration tasks in Sharegate using PowerShell scripts. In one of my previous project, we were migrating network shares to SharePoint Online using Sharegate as the migration tool of choice.

Based on our discussions with business divisions and IT department, the following requirements were identified for most of the divisions:

  1. Office documents, PDFs, Image files will be migrated
  2. Include only documents modified after a date for e.g. January 1, 2016
  3. Permissions should be preserved
  4. There were some exceptions where the identified divisions requested all available data to be migrated.

To address the above business requirements, we created custom migration templates and these templates were used to trigger the migration tasks. This allowed us to do use pre-created configurations for each migration and eliminate of manual overhead and risk of errors. Sharegate migration templates (.sgt files) are xml based configuration documents and encapsulate the configuration options such as:

  • Copy options
  • Content type mappings
  • Allowed extensions
  • Cut-off dates

Migration Templates

I’ll present two (2) migration templates, that were prepared to cover off the business requirements:

Template 1 – All data This migration template configures Sharegate to migrate all data to the destination library. The configuration values to be considered are:

  • CopyPermissions Specifies that all permissions on the files / folders be over [configured as “true”]
  • KeepAuthorsAndTimestamps – Specifies that the file / folder metadata such as Authors, associated time stamps (created date, modified date) be copied over [configured as “true”]
  • ContentFileExtensionFilterType – specifies file extension type filter to copy data [configured as “AllExtensions”]

 

Template 2 – Filtered Data This migration template configures Sharegate to migrate all the documents that was modified / created after 1st January, 2016 and matches one of the configured extensions to the destination library. The configuration values to be considered are:

  • CopyPermissions – Specifies that all permissions on the files / folders be over [configured as “true”]
  • ContentFrom – specifies the date cutover anything modified after this date shall be copied [configured as “01/01/2016 10:00:00”]
  • KeepAuthorsAndTimestamps – Specifies that the file / folder metadata such as Authors, associated time stamps (created date, modified date) be copied over [configured as “true”]
  • ContentFileExtension – specifies that all allowed file type to be copied over [configured as “pdf; xlsx; xls; doc; pptx; docx; ppt; xlsm; rtf; vsd; pub; docm; xlsb; mpp; one; pps; dotx; dot; pot; xlk; vdx; pptm; xlt; xlam; potx; odt; xla; wk4; dic; dotm; xltm; xltx; onetoc2; vss; thmx; vsdx; xps; msg; eml; jpg; cr2; png; tif; psd; bmp; eps; ai; jpeg; gif; indd; dwg; svg; djvu; ico; wmf; dcx; emf; xpm; pdn; cam; ”]
  • ContentFileExtensionFilterType – specifies file extension type filter to copy data [configured as “LimitTo”]

 

Migration templates in Sharegate user interface

The migration templates presented as XML files before may be imported into Sharegate user interface to inspect and test. Migration options are available while configuring a migration as demonstrated in the screen shot provided below:

 

The screen shots below represent the migration options as visible in Sharegate user interface, when the templates are imported into the tool.

Copy Options Screen – Template 1

Content type mapping screen – Template 1

Filter options screen – Template 1

 

Copy Options Screen – Template 2

Content type mapping screen – Template 2

Filter options screen – Template 2

 

PowerShell scripts to initiate migrations

Migrations can be initiated from PowerShell console by running the following script

 

The coded migration templates as demonstrated above has merits in terms of eliminating the need to manually configure options for each migration using Sharegate user interface.

To extend this to a whole new level, the overall migration project can further be split into multiple migration tasks and scheduled as sequential migrations across multiple machines utilizing common migration templates and scripts stored in a network location, but that is something I’ll cover off as a part of separate blog post.

Happy Migrating…

Automation and Creation of Office 365 groups using Flow, Microsoft Graph and Azure Function – Part 2

In the Part 1 blog here, we discussed an approach for the Group creation process and important considerations for provisioning groups. In this blog, we will look at getting a Graph App ID and App secret for invoking the graph service and then implementation of the group provisioning process.

MS Graph App Set up

Before we start creating groups we will need to set up a Graph App that will be used to create the group in the Office 365 tenancy. The details are in this blog here on how to create a Microsoft Graph app.

Regarding the permissions, below are the settings that are necessary to allow creating groups through the graph service.

GroupApp_Rights

Creating a Group

As discussed in Part 1 here, below are the broad level steps for automating group creation using a SharePoint inventory list, Microsoft Flow and Azure Function

1. Create a SharePoint list, with the metadata necessary for Group and SharePoint assets provisioning

We can use a SharePoint list to act as a trigger to create groups with the custom metadata necessary for provisioning the groups such as Owners and metadata necessary for creating site assets for SharePoint sites. As a best practice, I recommend you create multiple master lists to manage the details separately if there are too many to manage. In our case, we have created three separate lists for managing the Group details.

1. Group details and metadata
2. Owners and Team Members List
3. Site Assets configuration list

2. Create a Microsoft flow. The flow will validate a new or existing group and pick the unique Group Alias from the list which will allow us to find the group if it exists.

The flow will act as a trigger to start the provisioning process and call the Azure function passing the appropriate metadata as shown below. The flow also allows error handling scenarios as described in the Part 1 blog here

Note: The GroupAlias is the unique name of the Group and is not necessarily the SharePoint URL. For example, in the case where a group was created and subsequently deleted, the unique alias could be used again but the Site URL will be different (unless cleared from the SharePoint recycle bin).

Group_FlowAzureFunctionCall

3. Create the Group in an Azure Function using SharePoint Online CSOM

In order to create the group, we will need to authenticate to the Graph service using the Graph App created earlier. For authenticating the app through Azure AD, please install the NuGet Package for Microsoft.IdentityModel.Clients.ActiveDirectory.

After authenticating, we will create the group using the UnifiedGroup Utility provided through the SharePoint Online CSOM.

Below is a quick snapshot of the code. Note the inclusion of Graph module of the OfficeDevPnP class.

Note: One important bit to note is that, in the above code owners and members email array is the same. If the owners and members email array differ, then the group provisioning delays significantly. Also, it is important to keep the other parameters same as during creation in the below method because it might reset the other properties to default otherwise. For eg. if isPrivate is not set, then the group becomes public.

4. After the group is created, we can fetch the details of the group as below.

5. The group provisioning generally takes about 2-3 mins to provision. However, if there are multiple hits, then one request might override the second request causing the group creation to fail. In such cases, we can sequence the Azure Functions to run by modifying the host.json file. A quick blog covering this can be found here.

Provisioning SharePoint Assets in Azure Function after Group Creation

1. For provisioning of the SharePoint assets, we might have to wait for the Office 365 AD sync to finish granting access to the Admin account.

Sometimes, the AD sync process takes much longer, so to grant direct access to the SharePoint Site Collection using tenant admin, we could use the below code. Recommendation: Only proceed with the below code approach if the access fails for more than few mins.

Note: As a best practice, I would recommend using a Service Account when working on the SharePoint Site. We could also use an App as suggested in the Site Scripting blog here.

2. Once you have access, you can use the normal SharePoint CSOM to do the activities that are pertaining to SharePoint asset provisioning such as Libraries, Site Pages content, Lists, etc.

3. After you’re done, you can return the success from the Azure function as below.

Note: Use HttpStatusCode.Accepted instead of HttpStatusCode.Error in case there is error handling in the Flow or else Flow will trigger another instance of the flow when the Azure Function fails

Conclusion:

Above we saw how we can have a SharePoint Inventory list and create groups using Flow and Azure Functions. For a quick reference, below are the links to the other related blogs.

Part 1 – Automation and Creation of Office 365 groups approach

How to create a Microsoft Graph App

Sequencing calls in Azure Functions

Latest updates to Modern Libraries experience in SharePoint Communication sites (Apr 2018)

Modern Libraries in Communication Sites have got some welcome facelift during the last few months (Apr 2018) and there have been many great changes. I am going to list of few of these updates here.

Note: Some of these updates might be limited to Targeted release (or First release) versions only. In case these changes are not available then they might be not in Standard release ( or GA release) yet.

1. Full page view of SharePoint libraries

The SharePoint libraries now have a full page view, which provides it to use the full home page layout of Communication sites. It looks great 🙂

ModernLibExperienceSitePages

2. Custom Metadata support for Site Pages.

Now it is possible for newly created Communication sites (after Mar 2018) to have custom metadata updates with Site Pages content type.

Modern_Site_Pages_with_custom_content_type

Few catches in this scenario are:

1. It is still not possible to create a page by selecting a Child Site Page content type unless the child content type is set to default. When a page is created, it is set to default content type of the Site Pages library

2. Any communication sites, created prior to March 2018 mayn’t get this update. For associating metadata to site pages prior to Mar 2018, please check this blog for a custom approach to associate custom metadata to Site Pages. This will require custom code build for the same.

3. Support for more columns types through Modern UI Panel

Now we can create columns of additional metadata types such as Date, Choice and Picture with Modern Libraries, so don’t have to go to classic experience which is great from a UX and usability prespective.

ModernLibExperience_O3651

4. New command bar on Modern Libs

The Library command bar now provides a seemless experience of search and command items at the same level. Though small this is a great change because it would drive user to search content prior to creating new one.

NewCommandBar_SitePages

Conclusion

The above are some great updates for SharePoint modern libraries.

Set up a Microsoft Graph App for Office 365 and SharePoint Online management to use in Azure Functions, Flow, .Net solutions and much more

Microsoft Graph API can be used to connect and manage the Office 365 SaaS platforms such as SharePoint Online, Office 365 Groups, One Drive, OneNote, Azure AD, Teams (in beta) and much more.

A Graph app is an Azure AD app that has privileges (with provided permissions) to authenticate and then execute operations when using PowerShell, Azure Functions, Flow, Office Online CSOM, SharePoint Online and many other tools.

It is quite easy to set up a graph app, below is a brief preview of the process.

1. Go to the following link in your tenancy – https://apps.dev.microsoft.com/ and create an App. Below a brief screenshot of the App registration page.

GraphAppRegistrationScreen1

  1.  Then, first create a password and make sure to copy the password because it will be shown that time only. Also copy the App ID later for any future use.

GraphAppRegistrationScreen2

3. Then select the platforms that will be used to call the Graph app. For web calls use Web and for PowerShell scripts use Native as platform. You can leave the fields in the apps blank unless there is a specific endpoint that you would like to refer to. More information is provided at this link – https://developer.microsoft.com/en-us/graph/docs/concepts/auth_register_app_v2

Note: Turn off “Allow Implicit Flow” for web calls

4. Add the owners that could manage the App in Azure AD.
5. Next, select the proper application permissions that the App will need to run the actions. These settings are very important for your app to do the right calls, so try to set the appropriate settings. In some cases, it might be necessary to trial various app permission levels till you get it correct.

Note: For admin programs or scripts, it will be necessary to get Admin consent to the url below

https://login.microsoftonline.com//adminconsent?client_id=[clientid]&state=[something]

GraphAppRegistrationScreen7

6. Leave the other fields as is and create the App. We can turn off the ‘Live SDK support’ if not needed

GraphAppRegistrationScreen6

7. The App will show up in the Apps home page once created

GraphAppMyApplications

After the Graph app is created, we can use to perform various operations on Office 365 platforms. More details of the various operations are detailed here – https://developer.microsoft.com/en-us/graph/docs/concepts/overview.

There is also the beta release (https://graph.microsoft.com/beta/) which has more features upcoming in Graph Api.

Conclusion:

In the above blog, how we can create an Graph App that will allow us to connect to Graph Api and do operations with it.

Handle Throttling in SharePoint Online

Introduction

In this post I will be talking about handling throttling in SharePoint online custom code. I had recently faced throttling issue in custom CSOM code running from a console application which was working fine with the exponential delay pattern suggestion by community to handle throttling but lately started facing some issues.


Background

For one of our client we had console application to migrate documents from network file-share to SharePoint and update the corresponding managed metadata using the client side object model. The application was designed to read the list of files to be migrated from csv then pull the file from shared file location managed by another external tool, upload new files to SharePoint and then update the corresponding metadata. All these back and forth calls to SharePoint Online breached the threshold limits set on SharePoint online tenant.

There have been few guidelines suggested by Microsoft to avoid throttling the tenant from custom code.

In this case in order to handle throttling in SharePoint online we used the exponential delay after subsequent requests in order to avoid throttling. There is Git sample which can be used to implement the exponential back off technique.

Git sample helps with

  • Implement Incremental back off and retry pattern
  • Handle http web exception code 429

Problem

After including the exponential back-off as suggested in the above Git sample application was working alright but with some recent changes in Microsoft online tenant lately connection to the site was getting terminated with an exception “Addition to this website has blocked. Please contact your administrator to resolve this problem“.


Resolution

The exception was not very helpful. Once I started looking at the http traffic logs I realized that the CSOM traffic request that was sent to SharePoint Online was undecorated.

Undecorated traffic means when there is no AppID/ App Title or User Agent string for CSOM or Rest call made to SharePoint Online.

Decorated traffic will get prioritize over the traffic which is not properly decorated, so to give priority to the request it is recommended to decorate traffic using AppID/AppTitle or User Agent string in CSOM or REST API call to SharePoint Online.

SPO request was updated to include the user agent string as below

Another change which helped was to increase the client context request timeout property to set it to infinite.

Hope this helps with handling throttling in custom code in SharePoint Online application. Happy Coding!!

Automation and Creation of Office 365 groups using Flow, Microsoft Graph and Azure Function – Part 1

Automating the creation of Office 365 groups via an event triggered process can help business teams use a consistent template across all their groups, especially if there are numerous groups provisioned throughout the year.

For example, in our case we have 500+ custom Office 365 groups that are created and maintained each year. Hence in this case it became obvious we wanted to spin up an Office 365 group from a SharePoint list where users could make the request on their own. Below is a quick overview of the approach and some of the learnings from it. Hopefully this helps.

In this blog – Part 1, we will discuss the approach to the Group creation process and important considerations for provisioning groups. In the upcoming blog – Part 2, we will look at using the Graph App for invoking the graph service and then implementation of the group provisioning process.

Solution overview

The solution uses the below applications.

1. SharePoint List – Data Entry for Groups requests
2. Microsoft Flow – Handles events on the list item create and update
3. Azure AD Apps – Generate App ID and App secret for Graph API calls
4. Azure Function – Automation Code for applying additional rules on the SharePoint sites after the Group is created

High level business logic

The high-level logic flow of the process is as follows. First users make an entry into a SharePoint list. Next step, is to invoke a flow from the SharePoint list item. The flow is based on the defined rules and calls the Azure Function with appropriate parameters. The Azure function then creates the group using the Graph service and assigns owners and members to the group. After the group is created, the Azure Function also applies the later changes to the Group using the SharePoint CSOM.

After the Azure Function has created the group and provisioned the SharePoint artefacts, it will send the success response as the result. In the case of an error, it will reply with an error response.Office365GroupsProvisioningFlow

Important Considerations

For the above process we must make a few important considerations before implementation. There may be slight modifications based on these.

Azure Function Call Sequencing

The most important part of the above process is how we handle parallelism. The Microsoft graph service is not capable of too many subsequent requests from a single tenant, so to make it more robust we can sequence the Azure Function to handle only one request at one time. This can be done by modifying the host.json of the Azure Function as below.

{
  "http": {
    "routePrefix": "api",
    "maxOutstandingRequests": -1,
    "maxConcurrentRequests": 1,
    "dynamicThrottlesEnabled": false
  }
}

Group and SharePoint Site Permission Sync – A LONG wait…

Group creation is managed through an integrated provisioning process handled by Microsoft, so not all artefacts of an Office 365 group are created at the same time.  Some components are created instantaneously, such as the Exchange mailbox and SharePoint Site, but others take time to provision such as the AD Office Group security sync.  In some cases, the AD Security sync can take as long as 15 min to finish.  As such, we must wait to obtain owner level access.

For provisioning the SharePoint artefacts, you can use this blog to set the SharePoint site to allow site scripts.

Error Handling

Since the Group creation process is a long running process, it will be important to make sure that any failure is handled properly, and the process is re-run later.

In our case, we will use the Flow to handle any error case until we have a success as shown below. If you’re using an Azure Queue Storage trigger for the Azure Function, then we can use the Poison queue for handle error runs.

Office365GroupsProvisioningErrorHandlingInFlow

Conclusion

In this blog post we covered the broad level process of the Group Provisioning process, and some important considerations associated with it. Next, we will see how we can implement the remaining processes in the follow up blog.

How to make Property Bag Values indexed and searchable in SharePoint Online

In an earlier post here we have seen how we can set Property Bag values in Modern SharePoint sites. One of the major reasons for setting Property Bag values in SharePoint sites is to make the SharePoint sites searchable based on custom metadata.

However, property bag values are not crawled by the SharePoint Online Search index directly. To make a property bag value searchable, we must explicit set the property bag values to be indexed by the Search crawler. To do this, we simply set the Property bag values to indexed using the SharePoint PnP PowerShell.

The “-Indexed” attribute of the Set-PnPPropertyBagValue cmdlet makes an entry in a hidden system property bag value vti_indexedpropertykeys which then makes these property bag values searchable. A screenshot of the result is below.

SetPnPPropertyBagIndexed.png

After performing the above, we flag the site to be reindexed so that the SharePoint search crawler will pick up the new Property Bag values in the next crawl. This can be done from “Site Settings -> Search and offline availability” (in the Search group), then click the button “Reindex site” (screenshot below).

Note: Since SharePoint Online is a massive SaaS system, it can take up to 24 hours for the crawler to pick up this property.  Unfortunately, there’s no workaround for this delay, you simply must be patient.

Search and Offline Availability

Conclusion

In the above post we saw how we can enable Property Bag values to be searchable.