Author: givenscj

There are only a couple of posts on this across the web, none of which have any replies to them.  This is because this issue relates to any number of failures that can occur with the Workflow Manager service. 

One such error is when you attempt to send a DynamicValue as the request header to an HttpSend Activity.  If any of the headers have a significantly large string to them, you will cause a buffer overflow in the Workflow Manager Service. 

In Workflow Manager 1.0 RTM and service bus 1.0 RTM, this will lead to an error reporting service to consume the remaining memory on your application server and thereby rendering that app server useless.  In the Workflow Manager 1.0 Refresh and Service Bus 1.1 versions, the error simply kills the Workflow Manager service over and and over again.

There are several blog posts on this across the web, many will fix your issue, however, you may find that in some cases, none of them work for you. One such issue is if the configuration file of the Dist Cache has your machine registered, yet it cannot any details about that machine in SharePoint, you will get this error.  Even if you run all those wonderful SharePoint cmdlets.  The fix is to export the configuration file, remove the offending server, then upload the configuration file.  Then your SharePoint cmdlets will work:

1. Export-CacheClusterConfig c: empfile.txt
2. Remove the offending server
3. Import-CacheClusterConfig c: empfile.txt
4. Run the appropriate cmds to add it back

Here is all the scripts I have compiled that will help you to solve any issue you may come across:

  Get-AFCacheHostStatus | % {
    $ServerName = $_.HostName
    Get-AFCacheStatistics -ComputerName $_.HostName -CachePort $_.PortNo | Add-Member -MemberType NoteProperty -Name 'ServerName' -Value $ServerName -PassThru
} | Format-List -Property *   

Stop-SPDistributedCacheServiceInstance -Graceful;
Remove-SPDistributedCacheServiceInstance;

Add-spdistributedcacheserviceinstance

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

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

Register-CacheHost -Provider SPDistributedCacheClusterProvider -ConnectionString "Data Source=svr-jc-db1;Initial Catalog=SharePoint_Config_2013;Integrated Security=True;Enlist=False" -Account "NT AuthorityNetwork Service" -CachePort 22233 -ClusterPort 22234 -ArbitrationPort 22235 -ReplicationPort 22236 -HostName svr-jc-web2

Use-CacheCluster
Get-AFCacheHostConfiguration -ComputerName ComputerName -CachePort "22233"
Set-CacheHostConfig -Hostname SP2013 -cacheport 22233 -cachesize 300
Update-SPDistributedCacheSize -CacheSizeInMB CacheSize
start-cachehost
restart-cachecluster
Get-CacheHost
Get-CacheHostConfig -ComputerName SP2013 -CachePort 22233
Export-CacheClusterConfig c: empfile.txt
Import-CacheClusterConfig c: empfile.txt
Get-CacheClusterHealth

$farm = Get-SPFarm
$cacheService = $farm.Services | where {$_.Name -eq "AppFabricCachingService"}
$accnt = Get-SPManagedAccount -Identity domain_nameuser_name
$cacheService.ProcessIdentity.CurrentIdentityType = "SpecificUser"
$cacheService.ProcessIdentity.ManagedAccount = $accnt
$cacheService.ProcessIdentity.Update()
$cacheService.ProcessIdentity.Deploy()

Clear-SPDistributedCacheItem -ContainerType DistributedLogonTokenCache

Until further notice I am advising clients NOT to enable partner sharing.  This is because you never know who will be accessing your data from the partner side.  If your partner is a large SharePoint consulting firm, they have no ability to lockdown who can see your data on their side (out of the 100's or 1000's of clients they have). 

To be said another way, this means they have no way to keep random internal employees from checking out your site and data. Until they activate the ability to assign specific people to your accounts, I highly suggest that you stop partner sharing!!!

In other words, think Edward Snowden and Bradley Manning…type of security holes.

Vote for it here on UserVoice:

http://officespdev.uservoice.com/forums/224641-general/suggestions/5983421-enable-granular-permissions-for-o365-partners

As part of my 5-day O365 course I have a Workflow section that describes things like deploying workflows via Apps with event receivers that deploy to the Host Web.  Also a part of the lab is how to "theoretically" call an O365 API from workflow.  Unfortunately, you cannot call O365 APIs from workflows that live on-premises or in O365.  The reason is two fold. 

• For on-premises, there is a buffer overflow in the Workflow Manager service (1.0, CU1, CU2 and 1.0 refresh) that barfs on large DynamicValue HttpHeaders in the HttpSend request.  Reference this post for the error you will see.
• For O365, there is a special STS validation layer that barfs on the Azure AD access token (Error is "JsonWebToken.Issuer != clientId@realm"). If you pass the token in anything but the "Authorization" header it will pass right through, but it will not pass through in the "Authorization" header.

Therefore, the only avenue you have is to use "Basic" auth when making the calls.  This means you must store the user's username and password somewhere rather than allowing them to go through the basic OAuth process the way it should be.

If you would like to be able to do this, vote for it on UserVoice here:

http://officespdev.uservoice.com/forums/224641-general/suggestions/5981236-enable-azure-workflows-to-call-o365-apis

Updated as of 6/3/1024:

Since I am doing a lot with the O365 APIs at the moment, I figured it would be good to drop the O365 MVP list in addition to the SharePoint one.  I also attached the script to follow all of them below.  So here you go:

As promised, here is my blog post on how to extend SharePoint 2013 REST APIs! This post is similar in technical depth as the Extending Ceres engine post here.

The general premise is to add your own end points to the REST APIs in an on-premise environment.  This is a totally valid scenario similar to extending sharepoint with your own Service Applications.  This technique is used by the Project Server team (totally different team from the SharePoint team) to extend the ProjectServer and ProjectData REST end points.  I have published the sample project here. Here are the high level steps of what you must do:

1. Create a class decorated with ClientCallableType
1. Set the name to the same name as the class
2. Generate a new ServerTypeId set it
3. Set the FactoryType to a Object Factory that you will create next
2. Add methods and properties to the class, decorate with ClientCallable, ClientCallableMethod, ClientCallableProperty
3. Create the Object Factory that inherits from ClientCllableObjectFactory (this will create an class instance using an identifier)
1. Decorate the class with the Clietn
2. CallableObjectFactory attribute, set the ServerTypeId to the one you generated for the class
3. Implement the GetObjectById method
4. Create a ServerStub class that inherits from Microsoft.SharePoint.Client.ServerStub
1. Decorate the class with the ServerStub attribute, set the type to the class type, set the TargetTypeId to the ServerTypeId
2. Implement a public constructor
3. Override the following properties and methods
1. TargetType (returns typeof(class))
2. TargetTypeId
3. TargetTypeScriptClientFullName (the name of your client target type you will create next)
4. ClientLibraryTargets (what clients can call your rest endpoint)
5. GetProperty Method
6. InvokeConstructor method (for both the CSOM and REST calls)
7. Constructor implementations called from InvokeConstructor
8. InvokeMethod (this calls the object's method)
9. GetMethods (this is required to tell the $metadata endpoint what is available)
10. GetProperties (similar to GetMethods)
5. Create another class in a .Client namespace
1. Decorate it with the ScriptType attribute, set the name and ServerTypeId
2. Make it inherit from ClientObject
3. Create the properties and methods that match to your server side class
6. Create a ScriptTypeFactory that implements the IScriptTypeFactory interface
1. Implement the IFromJson method, use a switch statement to generate a Client class object based on the scriptType string
7. Create the ProxyLibrary.xxx.xml file
1. Deploy to the {SharePointRoot}/ClientCallable directory
8. Open the project's AssemblyInfo.cs file
1. Add a UrlSegmentAliasMap attribute
2. Add a ClientNamespaceMap attribute
3. Add a ClientTypeAssembly attribute
9. Deploy the Farm Solution
10. Perform an IIS Reset
11. Hit a "_/api/$metadata" endpoint, you should see your end point displayed!

Enjoy!
Chris

Last year (2014), 24 never before SharePoint MVPs were honored:

By Country Breakdown:

5    Canada
3    Belgium
3    United States
2    Switzerland
1    United Kingdom
1    Brazil
1    Costa Rica
1    Germany
1    India
1    Japan
1    Netherlands
1    Romania