Migrating server roles by using the WS Migration Tool (WSMT)

Migrating server roles by using the WS Migration Tool

• WSMT is command line tool that helps you migrate certain roles to server running Windows Server.
• WSMT is built-in, install-able feature of Windows Server 2012. WSMT can be install either by using Add Roles and Feature wizards or PowerShell.
• Migration tools will allow you to migrate a variety of roles and services
1. Migrate ADFS role services to WS 2012.
2. Migrate Health Registration Authority to WS 2012.
3. Migrate Hyper-V to WS 2012.
4. Migrate IP Configuration to WS 2012.
5. Migrate print and document services to WS 2012.
6. Migrate remote access to WS 2012.
7. Migrate Windows server update to WS 2012.

Role Migration from WS 2008 R2 to WS 2012:

• Install WSMT on the destination server running WS2012. At an elevated Windows PowerShell

Install-WindowsFeature migration

• Create deployment folders on the destination server running Windows Server 2012 (use SmingDeploy.exe).
  SmigDeploy.exe /package / architecture amd64 /os WS0R2 /path <deployment folder path>
• Copy the deployment folder from the destination server to the source server.
• Register WSMT on source servers by typing the following at an elevated command prompt in the copied directory on the source server:
  .\Smigdeploy.exe
• Load WSMT into your Windows PowerShell session. To load WSMT type: Add-PSSnapin Microsoft.Windows.ServerManager.Migration
• Type Get-SmigServerFeature at an elevated Windows PowerShell prompt to find out which feature can be exported from the local server.
• At this point of time, you would use cmdlets such as Export-SmigServerSettings, Import-SmigServerSettings, Send-SmigServerData and Receive-SmigServerData to migrate data and setting to the destination server.

Server-to-Server Authentication

• SP 2013 extends OAuth to implement a server-to-server authentication protocol that can be used by service such as SP 2013 to authenticate other services such as Exchange Server 2013 or Lync Server 2013 or services that are compliant with server to server authentication protocol.
• SP 2013 has a dedicated local server-to-server security token service (STS) that provides server-to-server security tokens that contains user identity claims to enable cross-server authenticated access.
• These user identity claims are used by the other services to lookup the user against its own identity provider.
• A trust established between the local STS and other server-to-server compliant services is the key functionality that makes server to server possible.
• For on-premises deployments, you configure JavaScript Object Notation (JSON) metadata endpoint of other server-to-server compliant service to establish this trust relationship.
• For other online services, an instance of Windows Azure Control Service (ACS) act as a trust broker to enable cross-server communications among the three types of servers.
• The new server-to-server STS in SP2013 issues access tokens for server-to-server authentication.
• In SP2013 and SP2010 trusted identity providers that are compliant with WS-Federation protocol are supported.
• The new server-to-server STS in SharePoint 2013 performs only the functionality that enables temporary access tokens to access other services such as Exchange 2013 and Lync Server 2013.
• The new server-to-server STS is not used for user authentication and is not listed on the user sign-in page, the authentication provider UI in Central Admin, or the People picker in SP2013.

Improvements in Claim Infrastructure in SP 2013

SP2013 includes following improvements in claim Infrastructure:

1. Easier migration from classic mode to Windows based claim mode with new Convert-SPWebApplication windows PowerShell. Migration can be run against each content database and each web application. This is in contrast to SP2010 products, in which the migration run against the each web application.

Parameters: Convert-SPWebApplication

 

Parameter	Required	Type	Description
Identity	Required	Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind	Specifies the URL of the web application that you want to convert, for example: http://mysite/app1
To	Required	System.String	Specifies the string Claims that dictates that the application needs to be converted to claims authentication mode.
AssignmentCollection	Optional	Microsoft.SharePoint.PowerShell.SPAssignmentCollection	Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used. Note: When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.
Force	Optional	System.Management.Automation.SwitchParameter	Forces the conversion of the web application.
RetainPermissions	Optional	System.Management.Automation.SwitchParameter	Specifies the account under which the cmdlet is run and retains the permission in the web application.

Detailed Description

Use the Convert-SPWebApplication cmdlet to convert the authentication mode of a Web application to Windows Claims authentication mode and migrate the user accounts in the content database to claims encoded values.

 

2. Login tokens are now cached in the new Distributed Cache Service (DCS). SP13 uses a new Distributed Cache Service to cache login tokens. In SP2010 the login token is stored in the memory of each WFE server. Each time a user accesses a specific WFE server. It needs to authenticate. If you use network load balancers in front of your WFE's, user needs to authenticate for each WFE server that is accessed behind the load balancer, causing possible multiple re-authentications. To avoid re-authentication and delay, it is recommended to enable and configure load balancer affinity (also known as sticky session). By storing the login tokens in DCS in SP13, the configuration of affinity in your load balancing solution is no longer required. There is also scale-out benefits and less memory utilization in the WFE's because of DCS.
3. Authentication Logging: more logging make troubleshooting easier.
1. Separate categorized-claim related logs for each authentication mode.
2. Information about adding and removing FedAuth cookies from DCS.
3. Information about the reason why a FedAuth cookie could not be used, such as a cookie expiration or a failure to decrypt.
4. Information about where authentication request are redirected.
5. Information about the failures of user migration in a specific site collection.

 

 

What's new in Authentication in SP2013

• SP13 includes improvements in claim infrastructure and authentication features that enable new server to server and app authentication.
• Applies to: SP13 Enterprise, SP13 Standard, SP13 foundation
• Enhanced claim based authentication make easier and enable new scenarios and functionality for exchange server 2013, Lync 2013 and apps in SharePoint Store and App Catalog.
• SP13 introduce the support for Server to Server and app authentication by utilizing and extending the Open Authorization 2.0 (OAuth2.0) web authorization protocol.
• OAuth is an industry standard protocol that provides temporary, redirection-based authorization.
• A user or a web application that acts on behalf of a user can request authorization to temporarily access specified network resources from a resource owner.
• Support for OAuth in SP13 allows users to grant apps in SharePoint Store and App Catalog access to specified, protected user resources and data (including lists, documents, photographs and videos) without requiring the app to obtain, store, or submit the user's credentials.
• OAuth allows app and services to act on behalf of the users for limited access SharePoint resources. Example: this enable an app, such as a third-party photo printing app, to access and copy the files in the specified folder upon user request, without having to use or verify the user account credentials.

User Authentication and Authorization in SP13

Authentication: User authentication in SP13 is the process that verifies the identity of a user who requests access to a SharePoint web application. An authentication provider issues the authenticated user a security token that encapsulates a set of claims-based assertions about the user and is used to verify a set of permissions that are assigned to the user.

Authorization: User authorization in SP13 is the process that determines the users who can perform defined operations on a specified rescores within a SharePoint web application.

Claim based authentication is default authentication in SP13 because Server-to-Server and app authentication are based on claim authentication.

Windows Classic authentication method is still available in SP13 and can be configured using PowerShell.

Authentication method supported by SP13

• Windows claim
• SAML -based claim
• FBA (Form Based Authentication)