Tag Archives: SharePoint 2013

Invalid URI error on attempt to create new web application

You may see the following error message on attempt to create new web application using SharePoint 2013 CA UI:

Invalid URI: The hostname could not be parsed.

Error message says: “Invalid URI: The hostname could not be parsed“, at the same time creation of web application using PowerShell may work just fine. This error can be caused by the fact that you have asterisk (“*”) as a value of Host name property in bindings of one of your existing web applications. Removing asterisk and leaving host name blank should resolve this issue.

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.

Switching SP2010 from Classic Mode to Claims Mode Authentication

SharePoint Server 2013 uses claims-based authentication as its default authentication model, and it is required to enable its advanced functionality. Using claims-based authentication has the following advantages over using Windows classic-mode authentication:

  • External SharePoint apps support. App authentication and server-to-server authentication rely on claims-based authentication. With Windows classic-mode authentication you are unable to use external SharePoint apps. You also cannot¬†use any services that rely on a trust relationship between SharePoint and other server platforms, such as Office Web Apps Server 2013, Exchange Server 2013, and Lync Server 2013.
  • Claims delegation without “double-hop” limitation. SharePoint can delegate claims identities to back-end services, regardless of the sign-in method. E.g., suppose your users are authenticated by NTLM authentication. NTLM has a well-known “double-hop” limitation, which means that a service such as SharePoint cannot impersonate the user to access other resources on behalf of the user, such as SQL Server databases or web services. When you use claims-mode authentication, SharePoint can use the claims-based identity token to access resources on behalf of the user.
  • Multiple authentication providers per one web application. When you create a web application in claims-based authentication mode, you can associate multiple authentication providers with the web application. It means, that, for example, you can support Windows-based sign in and forms-based sign in without creating additional IIS websites and extending your web application to additional zones.
  • Open standards. Claims-based authentication is based on open web standards and is supported by a broad range of platforms and services

There are several supported scenarios for migrating or converting from classic mode to claims mode authentication which performed with use of a number of Windows PowerShell cmdlets: you either switch your web apps on SP2010 before upgrade to SP2013 or you can convert SharePoint Server 2010 classic-mode web applications to SharePoint Server 2013 claims-mode web applications after you have SP2013 installed already.

Steps to switch your SP2010 web apps to claims based authentication:

1. Enable claims authentication for your web app.

$WebAppName = "http://portal.denallix.com" 

$wa = get-SPWebApplication $WebAppName

$wa.UseClaimsAuthentication = $true


2. Configure the policy to provide the user with full access.

$account = "Denallix\Administrator" 

$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()

$wa = get-SPWebApplication $WebAppName

$zp = $wa.ZonePolicies("Default")

$p = $zp.Add($account,"PSPolicy")




3. Perform the migration.


4. Provision claims


Once done you with these changes may verify that you are using Claims Authentication for your web application:

GUI way. In Central Administration navigate to web application management, select your Web Application and click on Authentication Providers button:

SP 2010 check web app authentication mode 01

It will open a window where you can verify your default authentication mode:

SP 2010 check web app authentication mode 02

 PowerShell way:

$web = Get-SPWebApplication "http://portal.denallix.com" 


It will return True or False depending on whether you have Claims Authentication enabled or not (screenshot below for enabled state):

SP 2010 check web app authentication mode 03

In case you have K2 components installed you may need to perform relevant configuration changes on K2 side (see Claims Authentication Configuration section at help.k2.com) which I will cover in separate blog post.

In case if you are in a mood for deep dive into what & why of claims authentication subject you may read through the following articles:

Identity (Management) Crisis (Part 1): The evolution of identity concepts

Identity (Management) Crisis (Part 2): Everything you (think you) know is wrong

Identity (Management) Crisis (Part 3): Solving the Identity Problem

Identity (Management) Crisis (Part 4): Selecting a Comprehensive Identity Management solution

Claims Based Identity: What does it Mean to You? (Part 1)

Claims Based Identity: What does it Mean to You? (Part 2)

Claims Based Identity: What does it Mean to You? (Part 3)

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.