Tag Archives: SharePoint

Unable to activate/uninstall K2 App: RemoveApp does not exist as a method of this SmartObject Instance

Sometimes when trying to activate or uninstall K2 4.7 App from App Catalog level or from the Site Collection level you can get the following error:

If you enable SmO logging you can trace that error actually happens on SmO level, more specifically with SharePoint Integration Helper Methods SmO and its Activate Site Collection method:

 System > SharePoint 2013 Integration > SharePoint Integration Helper Methods

*NOTE: Issue happens with Activate Site Collection method, not with Activate Site Collections one.

Sometimes clearing your browser’s cookies and cache or starting your browser using another user account or incognito / InPrivate mode helps to resolve this issue. But when those methods does not work  you may try to execute this method manually in the SmO Tester tool using K2 service account. The only required input property which you need is the SiteURL, the rest of the fields can be blank. This action should result in an output message “Success”. Once that’s done, you can go back to your SharePoint AppCatalog and Activate or Uninstall the K2 App from there – this time it should not give you any errors.

Provisioning SharePoint App Catalog in SP 2013/2016

Starting from SP 2013 we have to have application catalog in order to host SharePoint hosted apps which is part of SP App Model which replaces solutions you used to use in older versions of SharePoint.

This topic is documented both by MSFT and by IT community but the problem with any documentation that you have to internalize it to get clear understanding and even properly written explanations sometimes does not click for you until you do some hands on practice and, yes, internalize this information. Recently I finally decided to do some practice and create an app catalog from scratch in my test environment as well as jot down the steps which are easy to follow and more appropriate for those whose sole question is “I need an app catalog. How can I quickly set it up?”

Here is the steps:

1) Provision required service applications. You need to have Subscription Settings Service and App Management Service Applications provisioned and running. You need to use PowerShell to provision service apps:

Add-PSSnapin Microsoft.SharePoint.PowerShell

#Adjust -Identity parameter as necessary

$msa = Get-SPManagedAccount -Identity conundrum\sp_serviceapps

#Create the App Management Service Application

$AppPool = New-SPServiceApplicationPool -Name "AppManagementAppPool" -Account $msa

$AppManagement = New-SPAppManagementServiceApplication -Name "App Management Service" -ApplicationPool $AppPool

$AppManagementProxy = New-SPAppManagementServiceApplicationProxy -Name "App Management Service Proxy" -ServiceApplication $AppManagement

#Create the Subscription Settings Service Application

$AppPool2 = New-SPServiceApplicationPool -Name "SubSettingsAppPool" -Account $msa

$SubSettings = New-SPSubscriptionSettingsServiceApplication -Name "Subscription Settings Service" -ApplicationPool $AppPool2

$SubSettingsProxy = New-SPSubscriptionSettingsServiceApplicationProxy -ServiceApplication $SubSettings

Once this script has been executed make sure to start services from CA.

K2 - App Catalog required services

2) DNS part. You have to have separate app domain or wildcard CNAME  entry in existing domain (the latter is no go in production environments for security reasons). We need wildcard DNS entry just because we want dedicated DNS domain names for our apps but we don’t want to create new DNS records for each and every app which comes online. We also want to have our apps running in their own isolated DNS domain (separate TLD) outside of SharePoint – this is better isolation approach which comes with SP app model.

You can just create wildcard CNAME record in existing domain like that:

K2 - App Catalog Wildcard CNAME entry in existing domain

Once again this is “no go” from security POV and you either want separate TLD or sub-domain for your apps. Steps below describe how to create DNS sub-domain and wildcard CNAME entry in it.

Start DNS Manager snap-in, right-click on Forward Lookup Zones and select “New Zone…”

K2 - App Catalog creating sub-domain 1

Next you just go through New Zone wizard mostly accepting defaults with exception of the page where you have to specify your sub-domain name, which in my case is “apps.conundrum.com”:

K2 - App Catalog creating sub-domain 1 K2 - App Catalog creating sub-domain 2 K2 - App Catalog creating sub-domain 3 K2 - App Catalog creating sub-domain 4 K2 - App Catalog creating sub-domain 5 K2 - App Catalog creating sub-domain 6 K2 - App Catalog creating sub-domain 7

Once DNS sub-domain is created you can create wildcard CNAME entry which have to point to your SharePoint app server in your parent/main domain:

K2 - App Catalog sub domain CNAME record 1 K2 - App Catalog sub domain CNAME record 2

Here is how end result should look like in DNS Manager:

K2 - App Catalog sub domain CNAME record 3

What it gives you in the end? Thanks to wildcard CNANE DNS entry in sub-domain you can ping any name in this sub-domain and it always will be resolved to your SharePoint app server IP. Example:

K2 - App Catalog sub domain CNAME record - test

3) Create new App Catalog site collection. Go to CA > Apps > Manage App Catalog:

K2 - App Catalog creating App Catalog 1

Then select Create a new app catalog site and click OK:

K2 - App Catalog creating App Catalog 2

On the next page specify required values – Title, Web Site Address, Primary Site Collection Administrator and End Users, and click OK:

K2 - App Catalog creating App Catalog 3

After this App Catalog sites collection will be created and you will be able to browse it:

K2 - App Catalog creating App Catalog 4

4) Last touch 🙂 Configure App URLs. Go to CA and click on Apps to get to Configure App URLs link:

K2 - App Catalog Configure App URLs 1

On the next page you have to specify App domain and App prefix and  click OK These settings will shape your apps URLs.

K2 - App Catalog Configure App URLs 2

This concludes App Catalog configuration and you can now test your App Catalog. As proverb puts it “The proof of pudding is in eating” and by extension we can say that “The proof of App Catalog is adding some app(s) into it”.

“Value cannot be null. Parameter name: token” for K2 links on SP2013 site in SP2010 compatibility mode

When you migrate Sharepoint and K2 you may run into a problem where all K2 links for your site just give you “Value cannot be null.  Parameter name: token.” I end up having issue after just changing site collection compatibility range (for testing purposes, here is how to do it) and then creating new site within it in SP 2010 compatibility mode. Immediately it was possible to see that something is wrong/missing:

K2 - Value cannot be null for SP 2010 Compatibilty mode site

Here is how to fix this. What you need to do is configure classic windows claims to work with K2 from SharePoint Claims enabled site with K2 (see my earlier blog post on how to configure claims authentication for your site also there is related K2 help section). To configure classic windows claims for K2 you have to do the following:

1) Retrieve SigningCertificateThumbprint by issuing the following command in SharePoint 2013 Management shell:

(Get-SPServiceApplication -Name SecurityTokenServiceApplication).SigningCertificateThumbprint 

Copy returned value to use it on step 2.

2) Open SQL Server Management Studio and edit SQL script below by replacing value “CAEF8EEA3D68074C347AC9584E60C6FC406C8AAB” with one retrieved on step (1) in your environment.


INSERT INTO [K2].[Identity].[ClaimIssuer] (Name,Description, Issuer, Thumbprint, Uri, UseForLogin)

VALUES ('SharePoint Windows STS', 'SharePoint Windows Authentication', 'SharePoint', 'CAEF8EEA3D68074C347AC9584E60C6FC406C8AAB',null, 0)


UPDATE [K2].[Identity].[ClaimTypeMapping]

SET IssuerID=@issuerId


UPDATE [K2].[Identity].[ClaimTypeMap]

 SET ClaimType = 'http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname'


INSERT INTO [K2].[Identity].[ClaimTypeMap] (ClaimTypeMappingID, ClaimMappingType, OriginalIssuer, ClaimType, ClaimValue)

VALUES (2,'IdentityProviderClaim', 'SecurityTokenService', 'http://schemas.microsoft.com/sharepoint/2009/08/claims/identityprovider', 'windows')

3) Next you can check Identity.ClaimsIssuer table in K2 database:

SELECT * FROM [identity].ClaimIssuer

It should contain SharePoint Windows STS with appropriate thumbrint value:

K2 - Value cannot be null for SP 2010 Compatibilty mode site - Issuers

Once this is done that “Value cannot be null.  Parameter name: token” should gone. It seems that in my case thumbprint value changed in my environment (i.e. I’m pretty sure that entry for SharePoint Windows STS did exist in my ClaimIssuer table) though I’m not sure what triggered that change.

How to check whether the UPA properties are populated correctly for specific user

Certain SharePoint 2013 features as well as K2 for SharePoint need to have User Profile Application (UPA) working and its database populated with correct data.

Sometimes it is difficult to confirm whether or not UPA is correctly configured as SharePoint UI does not show you all the properties for the users. Moreover, even if UPA is not configured properly users still can login to SharePoint and successfully get OAuth tokern, and this fact complicates troubleshooting.

As a quick way to confirm that UPA is populated correctly for a particular user you may ask him to login to SharePoint and navigate to the following page:


It will return all UPA propeerties for the user. For OAuth tokens to work correctly following properties should be popluated: SPS-ClaimID, SPS-ClaimProviderID, SPS-ClaimProviderType, and SPS-UserPrincipalName.