One of the benefits of SharePoint 2013 is its ability to scale property for use in a multitenant environment.  In addition to having isolated webs, it also provides for isolation within service applications.  This means, that for instance, Company A can have a web that provides search results that are completely isolated from Company B.  Of those that can be partitioned, some of the most important are the BDC, Search, Managed MetaData and the Secure Store.  Here are the SharePoint 2013 Service Applications that can be partitioned.

Partionable:

Non-Partionable:

The key way SharePoint takes advantage of multi-tenancy capabilities is through Site Subscriptions.  Site subscriptions allow grouping of Site Collections of the same Web Application to consume the same features and service information.  The key thing to remember is that a site can only have one subscription at a time, and that it has to be managed through powershell.  Once a subscription is set up the service application can be partitioned.

To create a new subscription:

$subscription = New-SPSiteSubscription
Set-SPSite -Identity http:// mydomain.com/sites/billing  -SiteSubscription $subscription

Partioning:

When creating your service application, such as search, add:

-Partitioned

After migrating “My Sites” from SharePoint 2010 to SharePoint 2013, I wanted to convert the My Sites to claims and then move it over to ADFS 2.0 authentication.   I had no issues with migrating other SP2010 sites to SP13 ADFS claims.  After going through the process for My Sites, I was able to use Chrome and sign into the main site, and then clicking on the “My Site” link will took me to my correct migrated My Site / Profile by logging me in through ADFS.

In IE, however, this was a completely different story.  I could sign into the main site with ADFS just fine.  However, clicking on “My Site”, or navigating there directly took me straight in without ever prompting me to log in via ADFS.  It was defaulting to Windows Auth, even though I had turned off NTLM, and it created a NEW profile for me using my Windows credentials instead of using my existing claims based profile.

Even toggling off “Enable Windows Authentication” in Central Admin under “Authentication Providers” did not stop this from happening.  Windows Auth continued to persist even after disabling this.

It turns out the issue was on the client side (IE), which was to be expected.  The first thing I did was disable all the “Trusted Sites” and “Local Intranet” settings in IE, also turning off “Enable Integrated Windows Authentication”.  This however left me with a windows login prompt.

Finally, as a last attempt, I cleared out my cache in IE.  That did the trick.  Apparently an old cookie was somehow getting picked up and prompting me for Windows Auth instead of the desired ADFS auth.

I ran into a bit of an issue where one of our SharePoint 2013 farm servers was acting unusual when it came to the AppFabricCachingService. When logging in, we were getting some errors, which showed up in the logs as being related to the cache.  If you are having similar issues, you may want to try some of the following steps:

Starting the Distributed Cache Service

First, verify that it is showing as “Started” in Central Admin on the offending server under “Services on Server”.  If you are having trouble starting it, as I have occasionally experienced in Central Admin, try manually starting “AppFabric Caching Service” under “Administrative Tools”,  “Services.”  Then run :

Server Status: Unknown

The issue I ran into was when running “Get-CacheHost”, it a returned status of “Unknown” for one of the servers.

As first course, reprovisioning the service is a good start. I verified that the service was indeed running on the server in Central Admin, and the ran the following PowerShell on the troublesome server:

Remove-SPDistributedCacheServiceInstance

$instanceName ="SPDistributedCacheService Name=AppFabricCachingService"

$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring())
-eq $instanceName -and ($_.server.name) -eq $env:computername}

$serviceInstance.delete()

Add-SPDistributedCacheServiceInstance

Use-CacheCluster

Get-CacheHost

If you run this on the local server, and it is still showing as “Unknown” when running “Get-CacheHost”, you may need to run:

Start-CacheHost

It will prompt you to enter the name of your server, and the port.  After this, check your work by running Get-CacheHost again.

Running this indicated that all the services were “UP” across our servers, but this was when running Get-CacheHost on the troublesome server. When running Get-CacheHost on the other servers, we still got indications of status “Unknown”.

Check the Firewall Settings

This left me to think that perhaps the problem was not related to the service itself. Sure enough, when attempting to ping the troublesome server from one of the other servers, I received a “Request timed out” message.

I went into Windows Firewall and changed the settings to match the incoming settings of those on the other servers that were not having an issue. I attempted to reprovision the service again after that, and it began to work.

Restart Windows Time to Ensure Servers are in Sync

Another problem I discovered that can occur in situations like this is if the time on the servers gets out of sync.  This can also cause issues with the cache.  What you will want to do in this scenario is navigate to “Services” on the offending server, and restart “Windows Time.”

Change the CacheCluster Size

Another useful setting I found was to make all the hosts have the same size cache.  If you find one of them is not set to the same size as the other run (changing the CacheSize accordingly):

Stop-CacheCluster
Set-CacheHostConfig -CacheSize 1000 -HostName server1 -CachePort 22233

Specified host is not present in cluster

If you receive “Specified host is not present in cluster” when attempting to get the service up and running, you may want to run the following scripts:

First, check to see if it returns a correct entry.

Get-CacheHostConfig –ComputerName server1.contoso.com -CachePort 22233

That will give you the details for the servers cluster information, which should look like:

HostName        : server1.contoso.com
ClusterPort     : 22234
CachePort       : 22233
ArbitrationPort : 22235
ReplicationPort : 22236
Size            : 1229 MB
ServiceName     : AppFabricCachingService
HighWatermark   : 99%
LowWatermark    : 90%
IsLeadHost      : True

If it does not, and you get an error of “Specified host is not present in cluster.” Then try the following script:

Register-CacheHost –Provider [provider] –ConnectionString [connectionString]
-Account "NT AuthorityNetwork Service" -CachePort 22233 -ClusterPort 22234 -ArbitrationPort 22235
-ReplicationPort 22236 –HostName [serverName]

For “provider” and “connectionString” check the DistributedCacheService.exe.config , under “C:\Program Files\AppFabric 1.1 for Windows Server”, which will look like:

<clusterConfig provider=”SPDistributedCacheClusterProvider” connectionString=”Data Source=sql.contoso.com;Initial Catalog=SharePoint_Config;Integrated Security=True;Enlist=False” />

Restart Cache Cluster

Finally, if you are still experiencing issues getting the server to start, you may want to try restarting the Cache Cluster:

Restart-CacheCluster

Finally, if you are still having issues, I would heartily recommend this post, as it is the most useful one I have run across:  http://mmman.itgroove.net/2013/07/fixing-the-appfabric-cache-cluster-in-sharepoint-2013/

Here is a useful video for getting oriented with the cache service: