
Microsoft 365 & SharePoint Ecosystem (PnP) September 2020 update is out with a summary of the latest guidance, samples, and solutions from Microsoft or from the community for the community. This article is a summary of all the different areas and topics around the community work we do around Microsoft 365 and SharePoint ecosystem during the past month.
Thank you for being part of this initiative. Sharing is caring!
Got feedback, suggestions or ideas? – don’t hesitate to contact.

In this weekly discussion of latest news and topics around Microsoft 365, hosts – Vesa Juvonen (Microsoft), Waldek Mastykarz (Rencore), are joined by Tomasz Poszytek, an independent consultant and MVP from Poland.
They talk about Thomasz’s background and how we crew to be an independent consultant running his own business. Key tips from him for anyone who might be looking into doing the same. Discussions on the business automation and the different tools which we have had around these processes in past. Touching the challenge of the licensing models from Microsoft and how that has been simplified from the past… but could be further simplified in future.
Thomasz also talks about this experiences on being a project manager and how he decided to rather be a consultant. In this episode, 21 recently released articles from Microsoft and the PnP Community are highlighted.
This episode was recorded on Monday, September 7, 2020.
Did we miss your article? Please use #PnPWeekly hashtag in the Twitter for letting us know the content which you have created.
As always, if you need help on an issue, want to share a discovery, or just want to say: “Job well done”, please reach out to Vesa, to Waldek or to your PnP Community.
Sharing is caring!

In this weekly discussion of latest news and topics around Microsoft 365, hosts – Vesa Juvonen (Microsoft), Waldek Mastykarz (Rencore), are joined by. by Phil Worrell (Swisscom) – Community Evangelist based in Switzerland.
The trio discusses the significance of the datacenter and cloud adoption in Switzerland, embracing the new work reality, and REgarding 365 – a WW community of MVPs delivering opinions, interviews, conferences, blog posts, weekly talk show and support on everything Microsoft 365.
Waldek and the PnP CLI team are gearing up to ship v3.0 of PnP CLI for Microsoft 365 this weekend. In this episode, 17 recently released articles from Microsoft and the PnP Community are highlighted.
This episode was recorded on Monday, August 31, 2020.
Did we miss your article? Please use #PnPWeekly hashtag in the Twitter for letting us know the content which you have created.
As always, if you need help on an issue, want to share a discovery, or just want to say: “Job well done”, please reach out to Vesa, to Waldek or to your PnP Community.
Sharing is caring!
First published on TECHNET on Mar 06, 2017
This post is a contribution from Sohail Sayed, an engineer with the SharePoint Developer Support team
We recently worked on an issue with a customer configuring TFS build for SharePoint 2013
Customer followed the article https://msdn.microsoft.com/en-us/library/ff622991.aspx
There seems to be some changes compared to this article for resolving the SharePoint reference assemblies which I have listed below
As per the above msdn link to resolve the references we need to follow the below steps
It is recommended that you copy the SharePoint Server assemblies to the folder:
.. Program FilesReference AssembliesSharePoint
And then add one of the following registry entries:
For 64-bit systems:
HKEY_LOCAL_SYSTEMSOFTWAREMicrosoftWow6432Node.NETFrameworkv4.0.30319AssemblyFoldersExSharePoint15]@=
“<AssemblyFolderLocation>”.
Change
We could not find the HKEY_LOCAL_SYSTEM key in the registry.
Instead we had to update HKEY_LOCAL_MACHINESOFTWAREMicrosoftWow6432Node.NETFrameworkv4.0.30319AssemblyFoldersExSharePoint]@=
“<AssemblyFolderLocation>”.
However this change will not work on its own
We had to add the command line argument ” /tv:12.0″ to specify the tool version.
In addition we need to ensure the build is happening as 64 bit and not 32 bit and the build should be able to resolve the SharePoint references successfully.
In the dazzling array of services among the Microsoft cloud offerings, the rollout of TLS 1.0/1.1 deprecations is not being done all at once. This has lead to some confusion and questions around which endpoints are dropping the older TLS support and when.
Here I want to provide some dates and times of the endpoints, along with some .NET code guidance on how to use the newer TLS protocol (1.2), with some more information on TLS across the Microsoft Cloud.
So to begin, here are some of the endpoints that we know of.
| Service |
end date |
Release |
| Office 365 (Exchange/SharePoint/etc) |
|
|
| Office 365 Dod/GCC |
1/1/2020 |
|
| Office 365 consumer |
10/15/2020 |
|
| Graph |
|
|
| Graph Government |
8/5/2020 |
|
| Graph Consumer |
10/15/2020 |
|
| Azure |
|
|
| Azure Guest OS images |
1/1/2019 |
Family 6 release |
| Azure Application Proxy |
1/31/2019 |
|
| Azure intra-service traffic |
1/1/2020 |
|
| Azure SQL DB managed instance (pre SQL 2016) |
1/1/2020 |
|
| Azure Cosmos DB |
7/29/2020 |
|
| Azure File Sync |
8/1/2020 |
|
| Azure AD registration service in all sovereign clouds (GCC High, DoD etc.) |
8/31/2020 |
|
| Azure Automation |
9/1/2020 |
|
| Azure AD registration service in all commercial clouds |
10/30/2020 |
|
| Azure App Services (Web apps/functions/etc.) no announced timeline, can be set by admin still. |
?? |
|
If you are not sure about a particular endpoint, you can use this powershell to test the endpoint to see which versions of TLS it supports-
<#
Created by: whall
Date Created: 3/25/2020
Product Area Tags: Connectivity
Technology Tags: SSL TLS
Use Case:
Shows which version(s) of TLS is supported for a URL
Description:
When you run this, it checks each TLS type connection to see if it is supported.
Parameters:
-url this is the URL of the site you are testing against
Keywords: sockets secure https
Code Example Disclaimer:
Sample Code is provided for the purpose of illustration only and is not intended to be used in a production environment. THIS SAMPLE CODE AND ANY RELATED INFORMATION ARE PROVIDED ‘AS IS’
-This is intended as a sample of how code might be written for a similar purpose and you will need to make changes to fit to your requirements.
-This code has not been tested. This code is also not to be considered best practices or prescriptive guidance.
-No debugging or error handling has been implemented.
-It is highly recommended that you FULLY understand what this code is doing and use this code at your own risk.
#>
#TLS check
param([Parameter(Mandatory=$true)][string]$url)
function TLSAvailable([string]$url){
Write-Host =======================
Write-Host $url
Write-Host =======================
[System.Net.ServicePointManager]::SecurityProtocol = “Tls”
try{
$resp1 = Invoke-WebRequest -uri $url -Method GET -DisableKeepAlive
if($resp1.StatusCode -eq 200){
Write-Host “TLS/SSL 1.0 supported” -ForegroundColor green
}
}catch {
Write-Host “TLS/SSL 1.0 not supported” -ForegroundColor Red
#$_.Exception
}
[System.Net.ServicePointManager]::SecurityProtocol = “Tls11”
try{
$resp2 = Invoke-WebRequest -uri $url -Method GET -DisableKeepAlive
if($resp2.StatusCode -eq 200){
Write-Host “TLS/SSL 1.1 supported” -ForegroundColor green
}
}catch {
Write-Host “TLS/SSL 1.1 not supported” -ForegroundColor Red
#$_.Exception
}
[System.Net.ServicePointManager]::SecurityProtocol = “Tls12”
try{
$resp3 = Invoke-WebRequest -uri $url -Method GET -DisableKeepAlive
if($resp3.StatusCode -eq 200){
Write-Host “TLS/SSL 1.2 supported” -ForegroundColor green
}
}catch{
Write-Host “TLS/SSL 1.2 not supported” -ForegroundColor Red
#$_.Exception
}
Write-Host =======================
}
TLSAvailable -url $url
Azure Web Application Services
If you are running a .NET web application in the Azure web application services, you can set the TLS level under the application settings as below-

.NET Framework Code
If you are compiling your code for .NET framework 4.7 (4.7.1 for WCF apps) or later, it will use the default TLS version for the OS.
If you complied to a previous .NET framework version, it will use older versions of TLS unless you apply the right patch, and use one of the following methods-
- Set a registry setting to force all .NET code to use strong cryptography
- Set a config setting for the app context overrides to use the strong cryptography
- Add a line of code to change the TLS version used for HTTPS calls
Method 1 (System wide registry change)-
This enables something called strong cryptography which makes .NET use the strongest cryptography available currently. This affects all .NET applications with one registry change (per CLR version).
Enable strong cryptography for .NET CLR 4 versions (64 bit)-
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv4.0.30319]
“SchUseStrongCrypto”=dword:00000001
[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv4.0.30319]
“SchUseStrongCrypto”=dword:00000001
Enable strong cryptography for .NET CLR 2 versions (64 bit)-
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFrameworkv2.0.50727]
“SchUseStrongCrypto”=dword:00000001
[HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoft.NETFrameworkv2.0.50727]
“SchUseStrongCrypto”=dword:00000001
Method 2 (Config file change)-
Add the following to your .NET config file
<runtime>
<AppContextSwitchOverrides value=”Switch.System.Net.DontEnableSchUseStrongCrypto=false” />
</runtime>
Method 3 (Hardcoded in the application)-
Use this line of C# code in your application during the initialization so that all web calls will use the newer TLS 1.2 protocol-
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
If you are using PowerShell you can use the same object with this-
[System.Net.ServicePointManager]::SecurityProtocol = “Tls12”
More on these here-
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls
Browser Support (Edge/Chrome/Edge legacy/IE/Firefox/Safari)
The following clients are known to be unable to use TLS 1.2. Update these clients to ensure uninterrupted access to the service.
- Android 4.3 and earlier versions
- Firefox version 5.0 and earlier versions
- Internet Explorer 8-10 on Windows 7 and earlier versions
- Internet Explorer 10 on Windows Phone 8
- Safari 6.0.4/OS X10.8.4 and earlier versions
Edge chromium disabled 1.0 and 1.1 around July 2020 (ver 84).
For all supported versions of Internet Explorer 11 and Microsoft Edge Legacy (EdgeHTML-based), TLS 1.0 and TLS 1.1 will be disabled by default as of September 8, 2020.
TLS 1.3
The next version of TLS is already implemented in some browsers, and is just around that corner, but as of yet should not be causing issues since TLS 1.2 is just getting to the lowest mandatory version.
More information
For more information on the patches for various products and more details to some of the .NET settings related to TLS please see the following articles.
Azure
https://azure.microsoft.com/en-us/updates/azuretls12/
https://azure.microsoft.com/en-us/updates/?query=TLS
Windows/.NET/SQL/SharePoint (on-Prem)
SQL-
https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-microsoft-sql-server
SharePoint (this covers .NET/windows/SQL/browsers as well)-
https://docs.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/enable-tls-1-1-and-tls-1-2-support-in-sharepoint-server-2019
.NET 4.5-
https://docs.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/enable-tls-1-1-and-tls-1-2-support-in-sharepoint-server-2019#34—enable-strong-cryptography-in-net-framework-45-or-higher
.NET 3.5 update for TLS 1.1/1.2 support-
https://docs.microsoft.com/en-us/sharepoint/security-for-sharepoint-server/enable-tls-1-1-and-tls-1-2-support-in-sharepoint-server-2019#35—install-net-framework-35-update-for-tls-11-and-tls-12-support
.NET programming guidance-
https://docs.microsoft.com/en-us/dotnet/framework/network-programming/tls