Search This Blog

Showing posts with label SharePoint 2016. Show all posts
Showing posts with label SharePoint 2016. Show all posts

Tuesday, June 7, 2016

SAML-based Claims Auth in SP2016

SAML-based claims authentication in SharePoint Server 2016

SAML-based authentication requires 

  1. A Client Computer
  2. A SharePoint 2016 Server/Farm
  3. Claim Provider / IP-STS (example: ADFS)
  4. Identity Provider (example AD, LDAP) which contains the actual accounts and password 


Note:
ADFS and SAML claims are not required if you are using AD DS infrastructure in which the forest and domain trust each other. 


Trust Relationship for SAML-based claims authentication process

Steps
  • The ADFS Server must trust the Identity Provider for which it is issuing SAML Security Token.
    Note:
    In case of AD and ADFS in the same domain; the trust is implicit and therefore trusts the validation security credentials by its domain controllers
  • ADFS must also trust Security Token request for locations on the SharePoint 2016 Server
  • You configure ADFS with the URLs of SharePoint 2016 Web Applications as a Relying Party and then web pages of SharePoint 2016 Server and those URLs will now be trusted for SAML Security Token requests
  • The SharePoint 2016 Server must also trust ADFS Server that uses a Token Signing Certificate to sign the SAML Security Token that is issues.
  • To validate the Digital Signature on the Security Tokens issues by ADFS, we configured the SharePoint 2016 Farm with Public Portion of that ADFS Token Signing Certificate

The SAML-based claims authentication process

Step 1
Assuming that the Client Computer does not already have a Claims-based Security Token.

SAML-based claims authentication occurs when it makes an initial anonymous request of a secured SharePoint 2016 web page


Step 2
The SharePoint 2016 Server redirects the Client Computer to the ADFS Server to obtain a SAML-based login page for User Credentials (username/password)

Step 3
The User provides credentials (username / password) and the Client Computer sends them to the ADFS Server with a request for a SAML Security Token


Step 4
The ADFS Server validates the sent credentials (username/password) with the Identity Provider (Active Directory, LDAP etc.)

Step 5
After validating the credentials from Identity Provider; the ADFS Server
  • Constructs a SAML Security Token,
  • Sign the Security Token, and
  • Send this Security Token to the Client Computer

Step 6
The Client Computer sends a new request for the SharePoint 2016 Web Page and this time it includes the SAML Security Token that it(the Client Computer) received from the ADFS Server
Step 7
The Security Token Service on the SharePoint 2016 Server then creates a claim-based Security Token and stores it with the Distributed Cache Service on the SharePoint 2016 Farm.

Claims (username, password, email address or whatever info) in this Security Token are based on the Claims in the SAML Security Token from the ADFS Server

The SharePoint 2016 Server then creates and sends a Federated Authentication or FedAuth Cookie to the Client Computer


This FedAUTH Cookie contains an encrypted key or index to the Security Token.

If the User is authorized to access the requested web page on SharePoint through analysis of the claims in the Security Token created by Security Token Service of SharePoint 2016 and Configured Permissions on SharePoint Contents; the SharePoint 2016 Server then sends the contents on the requested web page on SharePoint.

For subsequent requests, the Client Computer uses the FedAUTH Cookie for authentication.

Note: 
All above steps are valid for SharePoint 2013 Server as well.

Reference:


Happy SharePointing

Wednesday, September 16, 2015

SharePoint / Office 365 New Migration API

New SharePoint / Office 365 Migration API

Introduction
In Microsoft Ignite 2015 conference;  new SharePoint / Office 365 Migration API is also announced. The new Migration API will enable the users to migrate contents (all sorts of contents, files, permissions, metadata etc.) from on-premises SharePoint Farm or local/share drives etc. to Azure BLOB Storage (a.k.a Azure Temporary Storage) as packages in batches and pushed in batches and finally Timer Jobs of SharePoint Online pulled the package into the Office 365SharePoint Online and OneDrive for Business.





With this new API; the speed of migrating Gigabytes (GBs) of data is almost five (5 times) than the old way of migration and no worries for CSOM call throttling.

The flow of migration is as follows


Step by Step Guide

Step 1 -  Install SharePoint Online Management Shell

Go to the SharePoint Machine and uninstall all previous versions of SharePoint Online Management Shell, then download it using this link and install it 


Once it is downloaded; run it "As Administrator" and execute this command in SharePoint Online Management Shell window

$cred = (Get-Credentials "")

This will pop-up a window to get the password. Please provide the password.

This $cred variable will be used later in the migration.

Step 2 -  Add 2 new folders in your local SharePoint machine

These folder will only contain XML files so will not occupy lots of space

Folder 1 Name: c:\temp\TempPackage
Folder 2 Name: c:\temp\FinalPackage

Step 3 -  Create Azure Storage Account

Create Azure Storage account and make note of the Account Name and Key for later use
1- Go to https://manage.windowsazure.com and login
2 - Create a new Azure Storage for temporary storage and keep account username and key value for later use

Step 4 -  Create New Migration Package and Upload to Azure Storage

Migration package can be created in 2 ways

  • From Local Fileshare
Folders and files in the local file share can directly uploaded to the Azure Storage using below PowerShell command

 New-SPOMigrationPackage
-SourceFilesPath 
$sourceFiles 
-OutputPackagePath $targetPackage

where


$srcFiles = {Source Files Path}
$targetPackage = {Target Package Path}



Example:

PS C:\> $azurePkg = Set-SPOMigrationPackageAzureSource -SourceFilesPath '\\fileserver\fileshare' -OutputPackagePath 'd:\temp\migrationpackage_source'

  • From On-Premises SharePoint Server
From On-Premises SharePoint Server; it is required to go through few extra steps. First use Export-SPWeb.  

The Export-SPWeb cmdlet exports a site, list, or library. 

Export-SPWeb [-Identity]  
-Path  
[-AppLogFilePath
[-AssignmentCollection
[-CompressionSize
[-Confirm []] 
[-Force
[-HaltOnError
[-HaltOnWarning
[-IncludeUserSecurity
[-IncludeVersions
[-ItemUrl
[-NoFileCompression
[-NoLogFile
[-UseSqlSnapshot
[-WhatIf []]

where

[Identity] = GUID or URL of SharePoint Site. It is required.

Path = Folder Path of the Export File. Since NoFileCompression property is used; this must be a folder path. It is required.

ItemUrl = URL of Web Application, GUID or SharePoint object to be exported. It is optional/

Please get other details from

Example:

PS C:\>Export-SPWeb http://spsite -path "d:\temp\exportpackagefilename.cmp"

Note:
The package named exportpackagefilename.cmp is NOT  READY for migration; 

So it is required to make it ready for migration to target destination using below command

ConvertTo-SPOMigrationTargetedPackage -TargetWebUrl $targetWeb 
-SourceFilesPath
$sourceFiles
-SourcePackagePath
$sourcePackage
-OutputPackagePath
$targetPackage
-TargetDocumentLibraryPath
$targetDocLib
-Credentials
$creds



Examples:

PS C:\>$targetPackage =  ConvertTo-SPOMigrationTargetedPackage -TargetWebUrl http://spsite                           -SourceFilesPath \\fileserver\sharedfolder\sourcefilesFolder-SourcePackagePath c:\temp\TempPackage-OutputPackagePath c:\temp\FinalPackage -TargetDocumentLibraryPath "SPDocumentsLibName"-Credentials $creds

OR In a SubFolder destination

PS C:\> $targetPackage = ConvertTo-SPOMigrationTargetedPackage -TargetWebUrl https://spsite -SourceFilesPath \\fileserver\sharedfolder\sourcefilesFolder  -SourcePackagePath c:\temp\TempPackage-OutputPackagePath c:\temp\FinalPackage\-TargetDocumentLibraryPath "SPDocumentsLibName"-TargetDocumentLibrarySubFolderPath "Libray/SubFolder"-Credentials $creds

For more details
The above PowerShell command will convert the XML generated in temporary folder (c:\temp\TempPackage) when executed Export-SPWeb command ] and saves/copy new targeted migration package metadata files to the final package folder [ (c:\temp\FinalPackage) ]
Note: You might need to provide password for the credentials
Uploading On-Premises SharePoint Package to Azure Storage
On-Premises SharePoint can be uploaded to Azure Storage using below PowerShell command
Set-SPOMigrationPackageAzureSource -SourceFilesPath $sourceFiles -SourcePackagePath $targetPackage -AccountName $azureAccountName -AccountKey $azureAccountKey -AzureQueueName $azureQueueName
Example:

PS C:\> $azurePkg = Set-SPOMigrationPackageAzureSource -SourceFilesPath $sourceFiles -SourcePackagePath $targetPackage -AccountName $azureAccountName -AccountKey $azureAccountKey-AzureQueueName $azureQueueName 

Step 5 - Submit Azure Package
Now the package is uploaded to the Azure Storage; the next big step is to submit the package.
Submit-SPOMigrationJob 
-TargetWebUrl $targetWeb 
-MigrationPackageAzureLocations $azurePkg 
-Credentials $creds
Example:

PS C:\> Submit-SPOMigrationJob               -TargetWebUrl = https://spsite               -MigrationPackageAzureLocations = $azurePkg               -Credentials $creds

Note for Credentials: SharePoint Online Credentials that has admin rights on Final Destination Site

Step 6 - Migration from Azure Storage to Destination (SPO, O365, OD4B etc.)
Once the package is submitted; now actual migration is happening between Azure Storage and Destination (SharePoint Online, Office 365, OneDrive for Business etc.). This migration process is based on Azure Timer Job which is a queue and serves on first come first server basis in a parallel fashion and not impacting or preventing other timer jobs executed at the same time. 
The real-time progress of the timer job can be viewed on Azure Storage Account queue and logs can be viewed in the Manifest Container of Azure BLOB Storage.
Note:
All the above process and scripts can be saved in a single PowerShell script (.PS1) file and re-use any time.
$Office365LoginID = "admin@bhmconsultings.onmicrosoft.com"
$adminSite = "https://bhmconsultings-admin.sharepoint.com"
$sourceFilePath = "C:\migration\SourceData\"
$packagePath = "C:\migration\SourcePackage"
$targetWebUrl = "https://bhmconsultings.sharepoint.com/sites/{target site name}"
$targetPackage = "C:\migration\TargetPackage"
$targetLibrary = "{Taregt Library Name. For examples 'Shared Documents'}"
$azureStorageAccountName = "{Azure Storage Account Name}"
$azureStorageAccountKey = "{Azure Storage Account Key}"
$azureStorageQueueName = "{Azure Storage Queue Name}"
#Get Credentials 
$credentials = Get-Credential {Office365 Login ID}
#Create package and upload to Azure Temporary Storage
New-SPOMigrationPackage 
-SourceFilesPath $sourceFilePath 
-OutputPackagePath $packagePath
#For On-Premises SharePoint migration ONLY 
ConvertTo-SPOMigrationTargetedPackage 
-TargetWebUrl $targetWebUrl 
-SourceFilesPath $sourceFilePath 
-SourcePackagePath $packagePath 
-OutputPackagePath $targetPackage 
-TargetDocumentLibraryPath $targetLibrary 
-Credentials $credentials
#Ready package for migration from Azure Storage to Destination
$SourcePackageInAzureStorage = Set-SPOMigrationPackageAzureSource 
               -SourceFilesPath $sourceFilePath 
               -SourcePackagePath $targetPackage 
               -AccountName $azureStorageAccountName 
               -AccountKey $azureStorageAccountKey 
               -AzureQueueName $azureStorageQueueName
#Submit above Package for Migration to Destination
Submit-SPOMigrationJob 
-TargetWebUrl $targetWebUrl 
-MigrationPackageAzureLocations $SourcePackageInAzureStorage-Credentials $credentials 
Migration Benefits and Limitations
The biggest benefit of using SharePoint New Migration API is SPEED which is 5 - 10 times faster (depending on the complexity) than using any exiting technology who are not using 
New APIs.
There are some minor limitations as well.
1. Need to manage Azure Storage for temporary storage of the package until migration is done and related cost.
2.Trust Microsoft Azure to send migration package for temporary storage 3. Azure Storage Limit = 500 TB 4. Max Size of Single BLOB container, queue, table = 500 TB 5. Target throughtput for single BLOB = 500 requests per second OR 60 MB per second 6 . See SharePoint Online and OneDrive for Business limitations here Happy SharePoint Migration.

Wednesday, September 2, 2015

SharePoint 2016

SharePoint 2016 IT Preview First Hand Knowledge

1 - Minimum Hardware & Software Requirements for On-Premises Deployments

Minimum Hardware Requirements

Database and SharePoint Servers: 64 bits, 4 Cores with 12-16GB RAM
                                                            System Drive : 80GB
                                                            Other Drive(s) : 100GB

Minimum Software Requirements

  • Operating System: Windows Server 2012 R2 or Windows Server Technical Preview
  • .NET Framework: .NET 4.5.2 Framework for Windows Server 2012 R2
                                     .NET 4.6 Framework for Windows Server Technical Preview
  • Database Server:    SQL Server 2014
  • Pre-requisites:        Similar as SP 2013 and all prerequisites can be installed manually or by                                      SharePoint 2016 prerequisite installer itself if not installed earlier.                                                Following are the required prerequisites
        • Application Server or Web Server (IIS) Role 
        • Microsoft SQL Server 2012 Native Client
        • Microsoft ODBC Driver 11 for SQL Server
        • Microsoft Sync Framework Runtime v1.0 SP1 (x64)
        • Windows Server AppFabric 1.1
        • CU Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB2671763)
        • Microsoft Identity Extensions
        • Microsoft Information Protection and Control Client
        • Microsoft WCF Data Services 5.0
        • Update for Microsoft .NET Frameworj to disable RC4 in Transport Layer Security (KB2898850)
        • Visual C++ Redistributable Package for Visual Studio 2013

2 - SharePoint Server Roles

SP 2016 IT Preview introduced MinRole feature so in SharePoint 2016 IT Preview can specify the SharePoint Server Role at the time of creating a new farm topology or at the time of joining an existing farm. All the required services will installed and configured automatically by SharePoint as per defined server role in an optimized way.

SharePoint 2016 IT Preview currently 5 types of server roles for an enterprise topology
  • Front End / Web Front End - For Web Front End related components
  • Application - For Background Services and Service Applications
  • Distributed Cache - For Distributed Caching
  • Search - Search Components, Services and Service Application
  • Custom - For all custom services that can't integrate in MinRole

Also MinRole also introduced a new parameter for PSConfig Command named LocalServerRole to specify the role at the time of SharePoint Configuration. The available values for this new parameter are
  • WebFrontEnd
  • Application
  • DistributedCache
  • Search
  • SpecialLoad
  • SingleServerFarm

3 - PSConfig Command Example


PSConfig.exe -cmd configdb  -create –server Name of Database Server –database Name of SharePoint 2016 Configuration Database –user SPFarm Service Account –password SPFarm Service Account Password –passphrase SharePoint 2016 Farm Passphrase                                      –admincontentdatabase Central Admin Database Name -localserverrole WebFrontEnd


There is also a user-interface option available for this configuration using PSConfigUI.exe



4 - Upgrade and Migration

SharePoint 2016 supports Database-Attach upgrade method from SharePoint 2013 to SharePoint 2016. The steps for the Database-Attach upgrade method are


  • Build and Configure SharePoint 2016 Farm
  • Copy all the content and service applications databases
  • Create Web Applications and Site Collections
  • Attach previous copied databases with the new web applications
and you upgraded them to SharePoint 2016.


Note:
More knowledge-base articles for SharePoint 2016 are coming. Stay tuned.

Happy SharePointing