Posts Tagged ‘SharePoint 2013’

Replacing missing named caches to a SharePoint Distributed Cache cluster

July 30, 2013 4 comments

A couple of days ago, I started seeing a large number of trace messages being logged to the ULS logs on a SharePoint 2013 farm relating to the distributed cache that looked like those pasted below. These message would repeat with a searing frequency of almost every second. Needless to say, this looked very bad for the server from a performance perspective.

07/25/2013 11:08:18.29 w3wp.exe (0x31BC) 0x3358 SharePoint Foundation DistributedCache ah24w Unexpected Unexpected Exception in SPDistributedCachePointerWrapper::InitializeDataCacheFactory for usage 'DistributedLogonTokenCache' - Exception 'Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode(ERRCA009):SubStatus(ES0001):Cache referred to does not exist. Contact administrator or use the Cache administration tool to create a Cache. at Microsoft.ApplicationServer.Caching.DataCache.ThrowException(ResponseBody respBody, RequestBody reqBody) at Microsoft.ApplicationServer.Caching.DataCacheFactory.GetCacheProperties(RequestBody request, IClientChannel channel) at Microsoft.ApplicationServer.Caching.DataCacheFactory.GetCache(String cacheName) at Microsoft.SharePoint.DistributedCaching.SPDistributedCachePointerWrapper.InitializeDataCacheFactory()'. 238c329c-bfb9-f0d8-7a04-fe9ab695789e

07/25/2013 11:08:18.29 w3wp.exe (0x31BC) 0x3358 SharePoint Foundation DistributedCache air4g Monitorable Token Cache: Failed to initialize SPDistributedSecurityTokenCache Exception: 'Microsoft.ApplicationServer.Caching.DataCacheException: ErrorCode:SubStatus:Cache referred to does not exist. Contact administrator or use the Cache administration tool to create a Cache. at Microsoft.ApplicationServer.Caching.DataCache.ThrowException(ResponseBody respBody, RequestBody reqBody) at Microsoft.ApplicationServer.Caching.DataCacheFactory.GetCacheProperties(RequestBody request, IClientChannel channel) at Microsoft.ApplicationServer.Caching.DataCacheFactory.GetCache(String cacheName) at Microsoft.SharePoint.DistributedCaching.SPDistributedCachePointerWrapper.InitializeDataCacheFactory() at Microsoft.SharePoint.DistributedCaching.SPDistributedCache..ctor(String nam... 238c329c-bfb9-f0d8-7a04-fe9ab695789e

07/25/2013 11:08:18.29* w3wp.exe (0x31BC) 0x3358 SharePoint Foundation DistributedCache air4g Monitorable ...e, TimeSpan timeToLive, SPDistributedCacheContainerType containerType, Boolean encryptData) at Microsoft.SharePoint.IdentityModel.SPDistributedSecurityTokenCache..ctor(String name, TimeSpan timeToLive, SPDistributedCacheContainerType containerType, Boolean encrptyData, TimeSpan minimumTokenExpirationWindow) at Microsoft.SharePoint.IdentityModel.SPDistributedSecurityTokenCacheInitializer.Init(Object state)'. 238c329c-bfb9-f0d8-7a04-fe9ab695789e

The key message above was the highlighted portion. Effectively, it was telling me that the DistributedLogonTokenCache was missing. So to investigate, I did the following through the PowerShell console.


This was alarming because the DistributedLogonTokenCache was not the only one missing. There should have been a bunch of other named caches here that seem to have gone missing too. To be precise, there should have been the following 10 named cache containers.

  1. DistributedDefaultCache
  2. DistributedAccessCache
  3. DistributedActivityFeedCache
  4. DistributedBouncerCache
  5. DistributedLogonTokenCache
  6. DistributedServerToAppServerAccessTokenCache
  7. DistributedSearchCache
  8. DistributedSecurityTrimmingCache
  9. DistributedActivityFeedLMTCache
  10. DistributedViewStateCache

Why? Because those are the several cache container types available in SharePoint 2013 and one of each of those is created during SharePoint configuration (psconfig) unless you chose to run configuration with the “/skipRegisterAsDistributedCachehost” switch during SharePoint installation on the server(s) in question. In fact, you can get the list above by checking the possible values of the SPDistributedCacheContainerType enumeration.

So now all of these seemed to be gone and try as I may, I couldn’t find the reason they vanished. I wasn’t seeing any errors relating to any of the other cache containers – only the DistributedLogonTokenCache. Maybe there wasn’t any activity on the farm I was monitoring that used the other caches or maybe the components that used those caches weren’t so dependent on them. Or maybe they just didn’t log failures to access the cache. In any case, I needed to restore them. I knew I could create a new named cache container using the New-Cache cmdlet but what I really needed to know was what the name of the named cache was to be.

I looked at my VM with a still healthy cluster for the answer and found the following:


Apparently, it uses the format SPDistributedCacheContainerType_FarmID to create the cache containers. Hoping that the whole setup was loosely coupled enough to allow the cache to be discoverable just through the naming convention, I tried the following command.

New-Cache -CacheName DistributedLogonTokenCache_<farmGUID>

Moments later, on checking the ULS logs again, the DistributedCache errors seemed to have ceased. This was good. I could now restore the other named cache containers in similar fashion. I still wish I knew what caused their mysterious disappearance but I am glad there is a way to get them back without complex wiring.


Configuring SharePoint 2013 to use Workflow Manager 1.0

This article covers the final step in the process of setting up SharePoint 2013 for the new workflow platform for SharePoint 2013 workflows. This is where SharePoint is connected to Workflow Manager services.

This post assumes you have already installed the Workflow Manager product and configured the Workflow Manager and Service Bus farms using either the Configuration Wizard or through PowerShell. Here, we shall go ahead and set SharePoint up to use the Workflow farm. Based on whether SharePoint is collocated with the Workflow Manager and whether communication between SharePoint and Workflow Manager over HTTP is allowed, the steps through which this configuration is performed are different and are documented here. For the configuration in this instance we are using SharePoint on the same farm as Workflow Manager and communication over HTTP is allowed.

Configuration on SharePoint is about creating a service application proxy for workflow that has the service endpoint configuration for the Workflow service. This is done through the use of the Register-SPWorkflowService cmdlet in the SharePoint Management Shell. There is no UI based way of creating this proxy through the Central Administration application.


Before we proceed to do this however, let’s take a look at a few things. Here, I am using the Get-WFScope cmdlet to view the scope at the root of the workflow service endpoint. Note: In order to get scope details you’d need to know the ScopeUri of the scope you’re accessing. Without knowing what scopes are on the instance, it is hard to know or remember all the URIs. There is no way to list available scopes through existing cmdlets. Here’s a PowerShell script that helps with this.


When we create a Workflow Service Application proxy, we add a combination of a SharePoint site collection and the URI of the scope in the workflow service that it is bound to. Looking at the above, we see that there is just one root scope at this point with no child scopes.

Typically, there would not be a Workflow Service Application or proxy on a fresh new SharePoint environment. Because of whatever experimentation I was doing on my trial environment, I already did have a pair.


When I tried to check the proxy status


This is understandable since I have not made the connection with the workflow service yet. Just so I understood how this was set up, I ran the following from the SharePoint Management Shell.

Get-SPWorkflowServiceApplicationProxy | Format-List *


This didn’t tell me much – in fact it told me it was Online which it quite clearly was not and could not be. So I tried the following set of commands.


Both scope name and service address come up null. Again, since we have not made the connection with the workflow service yet. I have the option of deleting this proxy set up and starting afresh. Just to see how Register-SPWorkflowService would respond to the existence of the proxy, I went ahead without deleting it.


And it went through just fine. Or so it seems from the silent return on the command above. So let’s verify.

First, on refreshing the proxy management page on Central Administration.


Splendid. Now to check on the proxy settings.


Nice. You can see that a new scope called SharePoint has been created and its address has been bound to the proxy. Let’s hit up this URI in the browser for a second.


Very cool. There is obviously a lot more going on here than when we hit the root scope URI. One thing that pops out is how the security configuration type is OAuthS2SSecurityConfiguration. This is why we used the AllowOAuthHttp switch parameter when running Register-SPWorkflowService. But all that for a different discussion. Next, a quick look again at the root scope.


Now checking for the scope in question – the one called SharePoint that is apparently connected to the proxy on SharePoint.


How do we know this is linked to the proxy we were looking at? Notice the GUID in the UserComments property? Compare that with the Id property of the service application proxy that we got above from running Get-SPWorkflowServiceApplicationProxy. But to have the proof of the pudding, let’s go get the “after” picture on SharePoint Designer 2013.


The default platform choice now is SharePoint 2013 Workflow. This means our configuration went through fine and we are done.

Update [6/20/2013]: Sometimes it has been found after all configuration has been completed that the platform selection doesn’t show up in SharePoint Designer 2013. If you have gone through all of the validation steps above to ensure that the connection has been made right, there’s no need to panic. Here are a couple of additional steps that help with troubleshooting…

1. If you are on a multi-server environment and you set up Workflow Manager on an app server, you have to remember that when you use SharePoint Designer, that works with your web server and therefore, in order to make a connection to the Workflow Manager end points, it will need the Workflow Manager client. Make sure you have installed Workflow Manager client on all of your farm servers.

2. Sometimes, it requires an IISReset on the server just to shake things up and get them connected properly. There are people who have reported not seeing the SharePoint 2013 Workflow option after configuration and come back the next day to find it magically appear. This is likely because their app pools got recycled overnight. Definitely worth a shot.

%d bloggers like this: