harbar.net component based software & platform hygiene

Multi Tenancy with SharePoint 2013: What’s new and changed

Print | posted on Saturday, July 28, 2012 7:29 PM

 

Introduction

SharePoint 2013 Preview introduces a number of new elements and additional considerations for multi tenancy deployments. This article is intended as a companion to my Rational Guide to Multi Tenancy with SharePoint 2010 article series and will cover what’s new and changed in this release with respect to configuration and functionality. It is assumed you are familiar with the material in the article series.

Please note that this article applies to the SharePoint 2013 Preview release. Things are likely to change between now and the final release of SharePoint 2013. I will update this article shortly after RTM.

This article is verified with SharePoint 2013 RTM.

Fundamentally not a great deal has changed. The majority of the configuration, operations and core functionality are the same as with SharePoint 2010. However as SharePoint 2013 introduces changes to existing services along with brand new ones, these services’ degree of multi tenant awareness also changes. We must also factor in the new functionality in the core SharePoint offering as it pertains to a multi tenant deployment.

I have an update to my provisioning scripts to include all the changes and new things in SharePoint 2013 along with a few other refinements, which will be published soon.

 

 


New and Changed Service Applications

Three new Service Applications are introduced in SharePoint Server 2013, along with substantial changes to two existing service applications. Here’s a summary of how these changes impact multi tenant deployments.

App Management Service
The App Management Service is the key infrastructure enabler for the new SP Apps platform. App Management allows the configuration of the App Store, Licences, App Purchases, App Catalog, App URLs and App Permissions.

Whilst the App Management Service is not required, as SP Apps are the future of customisation within multi tenant deployments, the App Management Service should be considered a pre-requisite core service, like the Subscription Settings service application. Indeed for the App Management Service Application to function there must be a Subscription Settings service application provisioned.

The App Management Service is inherently Subscription aware and does NOT need to be provisioned in Partitioned Mode (there is no option to do so anyway).

Appropriately most of the Apps configuration “moves” to the Tenant Administration site, allowing each tenant administrator to configure their individual settings from the Marketplace section:

1

The configuration of App URLs and Monitoring of Apps remains at the Farm scope, and appears exposed via Central Administration. However these pages are useless when in a multi tenancy environment! For some unknown reason Apps get it’s very own top level section in CA. Anyway the configuration of App URLs must be done via Windows PowerShell cmdlets, just like the other main tenant specific settings for MMS, BDC and UPA. This can be done at the time of provisioning or at a later date.

There’s quite some kerfuffle in the developer community about SP Apps since the release of SharePoint 2013 Preview. Ignoring all of the discussion about the new model’s strengths and weaknesses from a customisation perspective, SP Apps are a huge piece of the multi tenancy model in SharePoint 2013 and should not be underplayed. I will probably post more about SP Apps specifically over the coming months.

 

Translation Service
The Translation Service, also known as the Machine Translation Service, supports multi tenancy by means of its service application being created in Partition Mode. Similar to the Word Automation service application, there is no tenant specific configuration, and the service is managed at the farm level. However just like the Word Automation service, its database is effectively a queue and therefore needs to be partition or tenant aware.

 

Work Management Service
The Work Management Service does not store any data, and therefore does not need to be created in Partition Mode.

 

Search Service
The Search Service in SharePoint 2013 is completely re-architected. The provisioning of the service application and it’s constituent components changes significantly, however from a multi tenancy perspective all we need to do is create the service application in Partition Mode as we did with SharePoint Server 2010. What is brand new and you should like this, is that unlike SharePoint Server 2010 which did not expose any tenant specific configuration, Tenant Administration now provides access to all of the key settings. It’s a beautiful thing!

2

Many of the *.EnterpriseSearch* Windows PowerShell cmdlets also are partition aware and can be used to automate some of the above configuration. Note the Export and Import Search Configuration options above.

 

User Profile Service
The User Profile Service hasn’t changed at all with respect to multi tenancy, however it is important to note some of the critical aspects once again. The related bug where a UPA created with a Windows PowerShell session not running as the Farm Account prevents provisioning of the UPS service instance, has NOT been fixed. We still need to use the workaround here. There is also no change to the support of only a single OU per tenant for Synchronization. Furthermore it appears as if Active Directory Import mode does not understand Subscription IDs and therefore cannot be used with a Partition Mode UPA.

All other service applications remain unchanged in terms of their configuration for multi tenancy. Of course where features and functionality have changed (e.g. MMS and BDC) those changes are naturally also available from Tenant Administration. Indeed some of the Search configuration above takes you to the Tenant Manage Term Store page.

 

 


Additional Functional Elements

Feature Packs
Feature Packs provide the ability to constrain the Features available for a given tenant. The fundamental capability isn’t changed in any way here, but of course the Features in the product have. Thus the old Feature Pack definitions for SKUs are no longer valid. A new set of feature pack definitions are required encompassing all of the new Features in SharePoint 2013.

Information Rights Management Integration
Information Rights Management (IRM) integration can now be configured to be tenant aware, thus providing the ability for each tenant to have different IRM settings. This will be incredibly useful especially in federated IRM scenarios. At the Farm Level we can configure multi tenant support, and we then can add tenant specific settings as part of the tenant provisioning or at a later stage. IRM will then be available to our tenants within Library Settings.

5

 

 


Configuration

The good news here is that the large majority of configuration remains unchanged. With the exception of the creation of the Search service application, all of my previous Windows PowerShell scripts can be used as is, with no modifications. The other changes are simply additions to those scripts.

Configuring the App Management Service
Nothing exciting here, we simply start the service instance and then create the service application and it’s proxy. This is the exact same pattern as used in my previous Windows PowerShell scripts for the other services. We do not need to provide a –PartitionMode parameter.

# App Pools
$saAppPoolName = "SharePoint Web Services Default"

# App Management Specifics
$appsInstanceName = "AppManagementServiceInstance"
$appsName = "App Management Service"
$appsDBName = "ContosoFarm_AppManagement"


# Grab the Appplication Pool for Service Application Endpoint
$saAppPool = Get-SPServiceApplicationPool $saAppPoolName

<# Setup the App Management Service Application & Proxy and start the service instance
    no partition mode, aware of Sub IDs.
#>
Write-Host "Creating $appsName Application and Proxy..."
Get-SPServiceInstance | where{$_.GetType().Name -eq $appsInstanceName} | Start-SPServiceInstance
$appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $saAppPool -Name $appsName -DatabaseName $appsDBName
$proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc -Name "$appsName Proxy"

Write-Host "App Management Done!"

 

Configuring the Translation Service
Again, using the same pattern, we simply start the service instance and then create the service application and proxy. This time we add the –PartitionMode parameter. However, there is an “interesting” aspect to this guy. Creating the service application automatically creates a proxy, but it does not allow you specify a proxy name. It just uses the same name as used for the service application! If you care about consistent naming in your farm (and you should!) you have to delete that proxy and create another one, this time with the name you desire. This continues the trend of wildly inconsistent cmdlet behaviour in SharePoint!

# App Pools
$saAppPoolName = "SharePoint Web Services Default"

# MMS specifics
$tsInstanceName = "Machine Translation Service"
$tsName = "Translation Service Application"
$tsDBName = "ContosoFarm_Translation"

# Grab the Appplication Pool for Service Application Endpoint
$saAppPool = Get-SPServiceApplicationPool $saAppPoolName


<# Sets up Machine Translation service instance & service app and proxy 
    Creating service app creates a proxy with the same name as the service app!!
    That auto created proxy will also be in partition mode

    To keep the naming consistent we can delete the autocreated one, and make a new one
#>
Write-Host "Starting the $tsInstanceName..."
Get-SPServiceInstance | ? {$_.GetType().Name -eq $tsInstanceName} | Start-SPServiceInstance

Write-Host "Creating $tsName Application & proxy..."
$ts = New-SPTranslationServiceApplication -PartitionMode -Name $tsName -ApplicationPool $saAppPoolName -DatabaseName $tsDBName
Get-SPServiceApplicationProxy | ? {$_.TypeName -eq "Machine Translation Service Proxy"} | Remove-SPServiceApplicationProxy -Confirm:$false
$proxy = New-SPTranslationServiceApplicationProxy -PartitionMode -Name "$tsName Proxy" -ServiceApplication $ts -DefaultProxyGroup

Write-Host "MTS Done!"

 

Configuring the Search Service
As the Search service has had a complete overhaul, the old script is no longer valid. The good news is that the Windows PowerShell for working with the Search service and it’s constituent topology elements has been refined. The following script replaces the old version for deploying on a single server farm. Of course we would need to do more work in the topology arena if deploying in a real farm with articulated search roles. The only multi tenancy aspect here is the use of the –Partitioned parameter when creating the service application and proxy.

Add-PSSnapin Microsoft.SharePoint.PowerShell -EA 0


# App Pool
$saAppPoolName = "SharePoint Web Services Default"

# Search Specifics, we are single server farm
$searchServerName = "sp01" 
$serviceAppName = "Search Service Application"
$searchDBName = "ContosoFarm_Search"


# Grab the Appplication Pool for Service Application Endpoint
$saAppPool = Get-SPServiceApplicationPool $saAppPoolName

# Start Search Service Instances
Write-Host "Starting Search Service Instances..."
Start-SPEnterpriseSearchServiceInstance $searchServerName
Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance $searchServerName

# Create the Search Service Application and Proxy
Write-Host "Creating Search Service Application and Proxy..."
$searchServiceApp = New-SPEnterpriseSearchServiceApplication -Partitioned -Name $serviceAppName -ApplicationPool $saAppPoolName -DatabaseName $searchDBName
$searchProxy = New-SPEnterpriseSearchServiceApplicationProxy -Partitioned -Name "$serviceAppName Proxy" -SearchApplication $searchServiceApp

# Clone the default Topology (which is empty) and create a new one and then activate it
Write-Host "Configuring Search Component Topology..."
$clone = $searchServiceApp.ActiveTopology.Clone()
$searchServiceInstance = Get-SPEnterpriseSearchServiceInstance
New-SPEnterpriseSearchAdminComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance
New-SPEnterpriseSearchContentProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance
New-SPEnterpriseSearchAnalyticsProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance 
New-SPEnterpriseSearchCrawlComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance 
New-SPEnterpriseSearchIndexComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance
New-SPEnterpriseSearchQueryProcessingComponent –SearchTopology $clone -SearchServiceInstance $searchServiceInstance
$clone.Activate()


Write-Host "Search Done!"

 

Configuring (or not) Feature Packs
I don’t currently have a set of Feature Pack definitions corresponding to the SKUs of SharePoint 2013. I am not entirely sure I will actually produce them. The use of feature packs to represent SKUs is really only useful from a demonstration perspective, and it’s likely I would make mistakes. I am not the guy to be defining which of the vast number of features included are part of individual SKUs. Obviously if you are running multi tenancy in the real world and are using Feature Packs, you will already have a Feature Pack management toolset, and that will work with no changes for SharePoint 2013 Preview.

 

Configuring Information Rights Management (IRM)
IRM support for multi tenancy can be enabled via Central Administration or the updated Windows PowerShell cmdlets. In Central Administration, simply navigate to the IRM settings page as normal:

Central Administration –> Security –> (Information Policy) Configure information rights management

4

Then select the RMS server as normal and check the Check this box in multi-tenant configurations to allow tenants to configure tenant level IRM settings check box.

3

In Windows PowerShell we can use the updated Set-SPIRMSettings cmdlet:

Set-SPIRMSettings -IrmEnabled -UseActiveDirectoryDiscovery -SubscriptionScopeSettingsEnabled

There are no configuration options for IRM within Tenant Administration, so this configuration must be applied using the new Windows PowerShell *.SPSiteSubscriptionIRMConfig cmdlets. We could also build this into the tenant provisioning function of my previous scripts.

$sub = Get-SPSiteSubscription "http://www.contoso.com"
Set-SPSiteSubscriptionIRMConfig -Identity $sub -IrmEnabled -CertificateServerUrl "http://rms.corp.cotoso.com"

 


Conclusion

This article covers a number of new elements and considerations for multi tenancy deployments introduced with SharePoint 2013 Preview along with the necessary changes to the configuration and Windows PowerShell scripts from my Rational Guide to Multi Tenancy with SharePoint 2010 article series. To the cloud, baby!

 

 

.

Feedback

Gravatar

# re: Multi Tenancy with SharePoint 2013 Preview: What’s new and changed

Extremely helpful! Thanks

10/17/2012 5:42 PM | Anon A Mouse
Gravatar

# re: Multi Tenancy with SharePoint 2013 Preview: What’s new and changed

Hi Spencer,
Do you know what the Powershell commands are for setting a search service application in SharePoint Foundation 2013? I am finding that the commandlet New-SPEnterpriseSearchServiceApplication is not supported, so will throw an exception. Strangely the search service application is not an option within the 'manage service applications' interface - you have to use the Configuration Wizard to setup search, which means you end up with Guid based database names. Speaking of service applications in Foundation 2013, you can create a secure store service application, but Foundation throws a SKU error when you try to Manage the service application (e.g. to create the initial master key).

12/10/2012 6:32 AM | Alan Coulter
Gravatar

# re: Multi Tenancy with SharePoint 2013 Preview: What’s new and changed

Hi Thanks !

Dou you now if it's possible to do the same with SharePoint Foundation 2013 (Partionned Search) ?

12/11/2012 8:33 PM | Jordan
Gravatar

# re: Multi Tenancy with SharePoint 2013 Preview: What’s new and changed

Nice Article... Thanks

12/14/2012 7:48 AM | GYAN SHUKLA
Gravatar

# re: Multi Tenancy with SharePoint 2013: What’s new and changed

Alan: you cannot create the SPF Search service with Powershell

1/8/2013 4:24 AM | harbars
Gravatar

# re: Multi Tenancy with SharePoint 2013: What’s new and changed

Alan: the SPF Search SA cannot be created with PowerShell

1/8/2013 4:25 AM | harbars
Gravatar

# re: Multi Tenancy with SharePoint 2013: What’s new and changed

Jordan: SPF Search cannot be partitioned

1/8/2013 4:49 AM | harbars
Gravatar

# re: Multi Tenancy with SharePoint 2013: What’s new and changed

Hi Spencer,

Super Work. I'm basically a Lync and Exchage guy, with minimal SharePoint knowledge. Recently I was entrusted to setup multi-tenancy in 2013 and you explained it beautifully using the 2010 Environment. From what I understand

gallery.technet.microsoft.com/... would work for 2013 out of the box.

Then I would need to replace the Search portion in this script gallery.technet.microsoft.com/... with the new one you have explained above, and

finally provision the tenants using this gallery.technet.microsoft.com/...

Thank You again. Very appreciable.

1/14/2013 7:28 PM | Favad
Gravatar

# re: Multi Tenancy with SharePoint 2013: What’s new and changed

Great Work, really helpful

3/6/2013 5:52 AM | Manoj Karunarathne
Gravatar

# re: Multi Tenancy with SharePoint 2013: What’s new and changed

Great Work !, was really helpful.

3/6/2013 5:54 AM | Manoj Karunarathne
Gravatar

# re: Multi Tenancy with SharePoint 2013: What’s new and changed

Spencer; I owe you exactly 15 beers sir!

Much appreciated, those scripts gave me most 95% of everything I needed (I've tweaked for a multiserver topology) - great work

9/26/2014 2:46 PM | Brett

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 2 and 6 and type the answer here: