TLS Issue - The underlying connection was closed

Problem:  I have a console using CSOM that stopped working when the TLS settings were updated firm-wide.  The communication is between the console and a SharePoint farm, using CSOM, and now it no longer works.  The event log generates the following error message on the client machine: A fatal error occurred while creating an SSL client credential. The internal error state is 10013.

Initial Hypothesis: The outbound HTTPS traffic is the issue as the error is telling me that the mistake was creating the SSL client credential.  The console runs on a web server, and the TLS restriction change has caused the issue.  This issue is that the console running can't create an SSL client credential.  The TLS change was made to the console VM and not the SharePoint farm.  Here is the PS script to validate TLS versions written by Vadims Podans.

The post below helped me query the windows web servers to check the TLS settings using PowerShell.  I believe the outbound is controlled by the inbound TLS settings.

Resolution:  Change the console to use a know TLS version e.g., TLS1.2 as shown below:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Alternatively, revert the TLS setting in the registry. Apparently, this means your server is more susceptible to attack.

Alternatively, specify all the portocols you support from the calling client side application ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls | SecurityProtocolType.Ssl3;

Read this section if you are still having issues.
Factors that Influence Settings:
My CSOM console sits on a VM that hosts IIS, so there are three components to ensure connectivity excluding networking:
1.> SharePoint Server needs to support the TLS version
2.> VM hosting my console's outbound SSL is also set by IIS local TLS settings, so if I want to speak on TLS to the SharePoint server, I also need to have SSL enabled (or registry hacked) on TLS1.2 on the IIS VM hosting my console.
3.> My Console needs to support TLS 1.2 or all versions so it can negotiate for itself.  Regedit to check TLS setting is shown below:

More Info:
https://www.sysadmins.lv/blog-en/test-web-server-ssltls-protocol-support-with-powershell.aspx

Also look at this post to enforce TLS1.2

HKEY_LOCAL_MACHINE\SOFTWARE\\Microsoft\.NETFramework\\v4.0.30319

   SchUseStrongCrypto = (DWORD): 00000001

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\\.NETFramework\\v4.0.30319

       SchUseStrongCrypto = (DWORD): 00000001

Enforcing Authentication using the Windows IdP

Overview: SharePoint farms often have multiple Identity Providers (IdP) such as Ping or SiteMinder and you always need to have Windows for the Search and other reasons.  Often you need to force the browser or CSOM code to use a specific IdP, in my case, the Windows IdP needs to be used.

In Fiddler, I have added a header as shown below to enforce the browser uses the Windows IdP:

CSOM HTTP Header added to force usage of the Windows IdP:

Simple Code for a CSOM SharePoint Test Rig

Switch Master Page Minimum Permissions

Problem: Use the Client Side Object Model (CSOM C#) to add a new master pages to a site collection and switch the master page.

Initial Hypothesis: Writing to a site collection only required contribute rights or even "designer" rights at the web application permission level.

Resolution: The minimum permission set for changing master pages is "Full Permission" which a site owner and the site collection admin have.  So to switch master pages you need a high set of permissions.  UI allows master pages to be switched when the user only has "Design" permissions. This proof is flawed as the UI and CSOM permissions are different.  Can the UI have different permissions to the CSOM API???  Am I going mad.  
SPWeb object with Design user permissions cannot be updated and the API returns an "Access Denied Error" - Thanks to Sachin Khade for identifying this.

Updated 26/05/2017:  So the reply I got from the engineer who raised a Microsoft ticket is "SharePoint designer and  SharePoint GUI only need to have design permission to change the master page. This is because SharePoint designer is created as an extension of the SharePoint product. However, since CSOM calls are coded using Visual studio, the code flow involved in this is different and hence requires permissions that are higher than what SPD needs."

Summary: "Design" rights allow the user to change the master page using the UI however the same user cannot switch the master page using the CSOM C# approach.

Updated 26/05/2017: Thanks to Aswin Bhaskaran for working out a minimum permission set for using CSOM to switch the master pages on a site collection:

Note: "Design" rights can be applied at the Web Application Policy level allowing the accounts with "Design" rights the ability to add master pages.  The "Design" permission is only built into SP at the Site Collection level, I created the "Design" permission with the same permissions at the web application level to ensure my account in the Web app Design group has access to all site collections on my web app.

Note: Microsoft do not recommend customized master pages for O365 or future development.  Rather inject JavaScript to modify pages.

CSOM for Deployment of SharePoint sites and Assets

Problem:  Historically we built Site Templates and WSP to build up of SharePoint solutions.  With the current state of SharePoint it's not advisable to release Full Trust Code (FTC).

Initial Hypothesis: So I often tend to write CSOM for custom provisioning and asset deployment.  I utilise the Tenant Admin API for provisioning site collections and then CSOM SharePoint in C# to provision and deploy my assets.

Possible Resolution:
PnP has a great library to provision assets to base you solution on, customising and building XMLfiles allows you to quickly build repeatable SharePoint solutions that are easily configurable.
Also InstantQuick has a solution called IQApp that is worth a look at.

Provisioing Site Collections on-prem using the Tenant Admin API

Problem: Ability to provision Site Collections without using Server Side code.  Use CSOM and the Tenant Admin APIs.  This is a follow on the post: Provisioning Site Collections using CSOM (read it 1st).  Thanks to Sachin Khade, Frank M (check) and Alex N R (check) has given me his time to understand this: https://sachinkhade.wordpress.com/
I have reduced the Tenant Admin process into the least amount of steps that works.

The steps are:
Perform on an existing Web Application
Run the PS Script below:

1. Create SC using a team site site template STS#0
2. Set the AdministratorSite Type = TenantAdministrator
3. Add ProxyLibrary that add the TenantAdmin dll
4. Attach the Proxy to the existing Web Application
5. Enable SelfServiceCreation on the Web Application
6. IISReset

• Using the C# console create new site collections using the Tenant Admin API

PS Script

========

# The first section contains the variables you need to specify based on your needs

$webapp =  get-spwebapplication http://radimaging.co.uk:555 # My Web application (already exists)

$url = "http://radimaging.co.uk:555/sites/msotenantcontext" # Tenant Admin Site Collection used for provisioing (does not exist)
$WebsiteName = "Tenant Admin"
$WebsiteDesc = "Tenant Admin Site"
# better to use the site template "tenantadmin#0" using the team site site template "sts#0" causes
# an error msg (SubscriptionId can't be null), both work but you get less admin options # for provisioning.
$Template = "STS#0" 
$PrimaryLogin = "radimaging\psmith"
$PrimaryDisplay = "Paul smith"
$PrimaryEmail = paul.smith@radimaging.com
# Create a site collection and top level website
New-SPSite -Url $url -Name $WebsiteName –Description $WebsiteDesc -Template $Template -OwnerAlias $PrimaryLogin –OwnerEmail $PrimaryEmail
$web = Get-SPWeb $url
$web.CreateDefaultAssociatedGroups($web.site.owner,$web.site.secondaryowner,"")
$web.Dispose()

#Set the TenantAdmin SC
$site = get-spsite -Identity $url
$site.AdministrationSiteType = [Microsoft.SharePoint.SPAdministrationSiteType]::TenantAdministration
$newProxyLibrary = New-Object "Microsoft.SharePoint.Administration.SPClientCallableProxyLibrary"
$newProxyLibrary.AssemblyName = "Microsoft.Online.SharePoint.Dedicated.TenantAdmin.ServerStub, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
$newProxyLibrary.SupportAppAuthentication = $true
$webapp.ClientCallableSettings.ProxyLibraries.Add($newProxyLibrary)
$webapp.SelfServiceSiteCreationEnabled=$True
$webapp.Update()
Write-Host "Successfully added TenantAdmin ServerStub to ClientCallableProxyLibrary."
# Reset the memory of the web application
Write-Host "IISReset..."   
Restart-Service W3SVC,WAS -force
Write-Host "IISReset complete."

As always check out this post from Vesa Vuronen:

https://blogs.msdn.microsoft.com/vesku/2014/06/09/provisioning-site-collections-using-sp-app-model-in-on-premises-with-just-csom/

Provisioing Site Collections using CSOM - Tenant Admin API

Overview:  This post looks at provisioning site collections using CSOM.  You can also provision site collections for SharePoint using PowerShell or any Server side object model. 

Points to Note:
Programmatically you can provisioning new site collections using CSOM using 2 approached namely:

1. Tenant Admin API
2. Http Post method (mimic the SharePoint UI for creating a site collection)

Note: Neither approach allows you to specify the Content Database to connect to, you shall need to manage the CDB you site collection goes into using the round robin site collection OOTB method for on-prem SP. 
Note: Tenant Admin API does not allow the Quota template to be specified.  See the FAQ section in this post.
Note: Tenant Admin API requires the April 2014 SP CU or later
Note: the Search Service Application needs to be configured to handle multi-tenancy to work correctly.  As do other the Service Applications using partitions to support multi-tenancy.  If you already have existing running farm, the change is a considerable effort.  The SA need to be created in partition mode and cannot be amended after creation (you will need to re-create the service Application).
Note: Using the Tenant Admin API for SC creation - you don't get the usual SP groups such as owner, contributor and visitor - you need to manually create them.
Note: I don't believe you can use the Publishing Site Template using the Tenant Admin API.
The Tenant Admin Site Collection can reside on the same or another Web Application where the site collections shall be provisioned.  Each Tenant Admin Site Collection (has it's own site template 'tenantadmin#0') has a SubscriptionId (Subscription Group) and when using the Tenant Site collection to create a new site collection, the new site collection is given the SubscriptionId for the group i.e. you can't specify the SubscriptionId declaratively).

Outline of steps to setup the Tenant Admin API:

1. Service Application need to be configured in partition mode (important SSA are: search, UPA, MMS, BCS, SSS, there are more).
2. Enabling remote site collection creation using CSOM on the Web Application
3. Enable AdministrationSiteType property from a site collection to "TenantAdministration"
4. Enable SelfServiceSiteCreationEnabled on the Web Application
5. Set Up Tenant Admin for Multi Tenancy/setup subscription

More Information:

Multi-tenancy/Site subscriber explained by Bill Baer
Spencer Harbar's Rational Guide to Multi-tenancy is a useful resource
General guidance for hosters in SharePoint Server 2013 provides insight into Multi-Tenancy
https://technet.microsoft.com/en-us/library/dn659286.aspx

Scenarios where multi-tenancy potentially shall be used:

1. O365/SharePoint Online
2. SPO-D
3. Hosting companies
4. Government implementations such as G-Cloud
5. Large Enterprise (only with extreme requirements)

Notes on HNSC using Tenant Admin API:

• When creating a host name site collection with managed paths e.g. http://acme.com/sites/daffy, you need to create the corresponding root hnsc for the routing to work i.e. http://acme.com.
• Creating a hnsc with a path is consider creating a hnsc not a path based site collection or a combination of the naming.
• The manage path /sites/ which is already created works as it is already setup.  If you want another managed path you need to configure this separately.

Quota Limits:
Quota max storage size and code points are parameters in the CSOM Tenant Admin API, they don't set these values and you cannot set the quota templates using CSOM.  You only 2 options at this point in time is to use the UI and apply a template, not really an option for customers with hundreds, thousands or tens of thousands of site collections or you use PowerShell/ the Server side object model.

Permissions:
To be able to provision a new site collection, the account used to provision shall need to have contribute rights (it feels low and simple to me but that is the min) or higher on the Tenant Admin Site Collection.

Troubleshooting Tenant Admin Site Collection Provisioning:  Update 2017-06-28
I had tremendous problems with site collections not being completely created using CSOM and the tenant admin API on a new server that was provisioned by our engineering department.  There are a couple of IIS and farm setting you will want to review should you get this issue and our amazing team figured this out so it is not my credit.  Gonzalo, Uzzey and Anthony with thanks!

Change IIS timeouts on the WFE's and SP farm configs, this made the site collections provision completely correctly.