I recently bump into an issue with HTTPS binding configuration for SSRS 2014. Instance was not touched for quite some time and self-signed HTTPS certificate expired. I generated new one and was trying to add new binding but SSRS console was keep removing HTTPS binding immediately after adding it with “We were unable to create the certificate binding.” message. I believe it was accompanied by HRESULT: 0x80040241. Internet is full of information on the problem and it looks like this thread, for example contains exhaustive list of things you need to check. But basically it turned out that beyond review and manual clean up of urlacls (netsh http show urlacl / netsh http delete urlacl) it was also necessary to copy my self-signed PS generated certificate from machine Personal store into machine Trusted root certificates store (hint was found here).
In a nutshell: when adding SSRS binding fails you need to know that those are not represented nowhere in IIS GUID, update your certificate (remove old, add new and be sure it is trusted on a Trusted Root level), next be sure you use right (non occupied by other services) ports and host names clearing up SSL reservations if necessary ( netsh http show urlacl / netsh http delete urlacl). Read error message you have and drill down into details to see error code – despite not showing its site and bindings in IIS console SSRS console does everything it can to say you what’s wrong / why it can’t proceed with adding binding, though I do admit underlying infrastructure of scattered configs and urlacls reservation can be intimidating at times.
Just a short note on how to collect process dump including LeakTrack information.
Download latest version of Microsoft Debug Diagnostic Tool, at the moment it is Debug Diagnostic Tool v2 Update 3 and install it going through an installation wizard steps as shown below:
Once installation wizard completes, download ProcDump and unzip it on the server where you going to collect dump file. Next, run DebugDiag 2 Collection:
Cancel out initial “Select Rule Type” dialog:
Navigate to Processes tab select process for which you need to collect LeakTrack, right click on it and select Monitor For Leaks:
Click Yes in “Do you want to enable ‘Service Mode’ and continue” pop up:
You will see confirmation that monitoring for leak has started:
Now let it run and wait till the process you monitor use up large amount of RAM and take dump using procdump.exe, you can see some hints on the command line syntax below:
Once dump taken you can stop monitoring for leaks and close Debug Diagnostic tool:
After following steps above your process memory dump should contain LeakTrack information. You can tell that by the dump file size – if you take a dump without enabling Monitor For Leaks option in Debug Diagnostic Tool at the same time you will see that your dump file size will be smaller if compared with one which you take while running Monitor For Leaks .
Just a short explanation of how to take process dump using CDB.
First you need to get Debugging Tools for Windows. To get Debugging Tools as a standalone tool set you can just download Windows SDK and during installation select Debugging Tools for Windows:
Once Debugging tools for Windows are downloaded and installed
you can find cdb.exe in the following location – C:\Program Files (x86)\Windows
Kits\10\Debuggers\x64 (note that number
highlighted in bold may vary depending on SDK version installed – in my case it
is 10, and you obviously have cdb.exe for different platforms – x86/x64 etc. –
just navigate to appropriate subfolder of Debuggers folder).
To take dump launch CMD in elevated mode, switch directory to CDB location and execute cdb -p <PROCESS PID> to take crash dump (remember that PID information can be found in Task Manager or retrieved with PowerShell using Get-Process “%ProcessName%” | select -expand id):
At this stage CDB is attached to process and closing this
CMD window will terminate process you are attached to. Once CDB is loaded type
in the following commands:
..loadby sos clr
You will receive
“No export Thread found” error – it can be ignored, and some more commands needs
to be executed. First run !StopOnException
-create System.StackOverflowException it may not work from the first attempt,
just re-run it once again until you see confirmation that breakpoint was
breakpoint is set type gn and wait
for process crash:
process crashed the following commands have to be executed:
.dump /ma /u C:\dumps\process.dmp
gn until you get “there is no debugee” message. Your dump will be written in
the location you specified above (C:\dumps\process.dmp).
Some time ago I wrote a blog post where I explained how to change SQL Server instance collation for installed SQL server instance (see “Changing SQL collation for deployed instance without reinstall (almost)“). That post contained some scripting bits to detect installed SQL Server version and navigate to appropriate setup directory to facilitate collation change process. Recently I had a bit of time to consolidate these bits of PowerShell into one script which detects installed SQL Server version and changes directory to appropriate setup folder. Here you have it:
This blog post is just a short
walk-through explaining how to switch your K2 environment from Windows to Forms
authentication. Just to provide you an example of when you may want this – you
can use this configuration when you want to get password prompt on token
expiration while all your forms users working from domain joined workstations
belonging to K2 server domain (that means that STS token refresh will be
happening without any extra password prompts using existing Windows user
credentials to obtain STS token).
Required steps are described in K2 documentation (look under “Forms
Authentication”) but at the moment it does not mention some required steps
which we will cover here.
To switch over to Forms
Authentication you first need to navigate to K2 Management > Authentication
> Claims > Issuers section of K2 Management site:
There you can select K2 Forms STS and Click Edit button to enable “Use for Login” option of this issuer:
Once you enabled this option, switch
over to Authentication > Claims > Realms:
Here you need to edit every realm
and link K2 Forms STS issuers to it (depending on your needs you can do that
only for some realms):
Once you do that your realms should
have K2 Forms STS visible in LINKED ISSUERS column:
At this point if you restart your
browser and try to access K2 sites you will be presented with login method
selection which looks as follows:
If you don’t like this dialog or do
not need to use multiple logon methods just uncheck
“Use for Login” option for K2 Windows STS issuer, with such
configuration you will be getting immediate form authentication prompt on
attempt to access K2 site (and after K2 STS token expiration). This is how it
Up to now we were following steps
from K2 documentation and completed them but if you try to login with correct
credentials you may see the following error:
Error message has the following
Claim mapping configuration cannot be found for this claim. Claim information:
Name='DENALLIX\administrator', Issuer='FormsSTS', Original Issuer='FormsSTS'.
Please ensure that you have configured the K2 server as specified in K2 Help:
Installation and Configuration > Configuration > SharePoint >
tokenXml, ClaimsTokenType tokenType, ClaimsVersion claimsVersion)
sessionCookie, String tokenXml, ClaimsTokenType tokenType, String
connectionString, String authReqSource, ClaimsVersion claimsVersion)
This error and corrective actions to
it do not mentioned in product documentation. To fix this you have to do the
1. Edit K2TokenService.exe.config
located in “%K2_INSTALLATION_ROOT%\Token Service\Bin\” adding your K2
service and K2 application pool accounts into allowedCallers section as
Here is sample of allowedCallers section
2. Save your changes and restart K2
Claims To Windows Token Service aka K2WTS (you can use PoSh command for that –
After performing these steps you
will be able to logon to K2 sites using forms authentication.