Category Archives: K2

“Method not found error” when attempting to add a new item into K2 Studio project

The other day I was about to build some tiny K2 test project using old-fashioned thick designer UI K2 Studio which I still prefer to use whenever I need to build some little K2 process. Unfortunately I bumped into this error:

Error message politely informs us about this:

Method not found: ‘Microsoft. Build. BuildEngine

BuildItem SourceCode. ProjectSystem. ProjectBuildItem


That’s not very obvious, right? But, trust me it just complains that some DLL is not properly added to GAC, or there is a mismatch between DLL version in GAC and in some other location.

Solution? If you run K2 environment without coldfixes just run a Repair from installation media. But most likely you’ve applied some coldfix recently. Verify if files which supposed to go to GAC were added to that location correctly. Remember that some files go to K2 installation directory, while some others may go to “[Program Files]Reference Assemblies\SourceCode\v4.0\” and into GAC v4, i.e. into “C:\Windows\Microsoft.NET\assembly\GAC_MSIL\”. In my case the error was caused by the fact that SourceCode.Workflow.Authoring.dll assembly was not updated in GACv4.

When something wrong with aforementioned DLL you will also see the same error when trying to deploy something with PnD:

So in case you getting this type of error you know what to check now.


Do I need to restart K2 host service if I added “NewtonJson.dll into GAC?

Today I was asked by my colleague something on the lines “Do I need to restart K2 host server service if I added “NewtonJson.dll into GAC?”

This is quite an interesting question which I would re-phrase as “Do I need to restart K2 host server service if I added DLL X in location Y?” Unfortunately there is no easy answer, though you may assume that developer should know this for sure. That’s a bit of a myth that “developer as a creator of a program can predict any output from the app for any given input”, and explanation to that phenomenon has surprising parallels with much sought after in middle ages explanation of “how is free will possible in the light of the fact that there is an almighty and all knowing creator in this universe”, buy I guess I will save this philosophical topic for separate blog post.

I’ve split this question into some sub-questions and checked with one of the developers (only to confirm all that was said above).

How K2 service loads DLLs?

It all differs from DLL to DLL.

Little clarification (as I was pointed out that I’m using outdated terminology): DLL stand’s for Dynamic-Link Library and I employ it to refer to any files with DLL extension since my DOS gaming days, whereas modern official term commonly used by developers is assembly. Term comes from the new Global Assembly Cache (GAC) infrastructure. This is machine-wide CLI assembly cache for the Common Language Infrastructure (CLI) in .NET Framewrok, which was designed to allow for specially controlled central repository which addresses the flaws of the shared library concept and helps to avoid DLL hell.

Getting back to the question above: some assemblies we may load in memory on startup and keep there till service restart, but some may be called as needed an then disposed (though again you can’t easily tell when they are disposed, except for service restart). Among those which “load on demand” some loaded by K2 service while others are loaded automatically by .NET. But we have two GAC repositories on modern Windows platform one for .NET v2 and another for .NET v4 and sometimes the same assembly exist in two versions and which one called depends on your application code.

As you can see things can be quite different and it all depends.

Just to illustrate: I remember an issue which may be reproduced in old (pre-4.7) versions of K2 when you erroneously place to GAC SourceCode.Workflow.Resolver.Data.dll. It should not be there in the first place, but if you place it there it is trying to call another DLLs (SourceCode.Workflow.Functions.dll) from current directory as both of them exist in K2 bin folder. Yet as soon as 1st DLL landed to GAC it takes priority over one from the Bin folder, but then errors out as it can’t see 2nd DLL in GAC. So on versions prior to 4.7 workflow will enter into Error state with the following error logged in Error profiles: Assembly ‘SourceCode.Workflow.Functions’ could not be found. In 4.7 workflow will enter into Error state with more actionable error message: “Please remove SourceCode.Workflow.Data.Resolvers from the Global Assembly Cache.”

Do I need to do K2 restart after I GACed NewtonJson.dll, for example?

Probably. NewtonJson.dll is a 3rd party dll K2 uses for JSON serialization and some other things. And whether restart is needed depends on what K2 DLL is using it, but the safest option is always perform a restart of the service. Even IIS sometimes keep a cached copy, and does not use the new one if you replace it until iisreset is performed.

Is there some (relatively) easy way to tell which DLLs can be safely replaced without K2 service restart?

Here we can think that some debug utilities should exist which may tell you which assemblies are used by specific process. I don’t know any of the top of my head and have to reseatch this separately. Normally, if you can overwrite the file, then it already means it is not being used at the moment. But, for example, IIS is different, as it keeps a cached copy in a temp folder somewhere. So it all depends on how specific DLL is loaded/used by each specific service – it may be loaded in memory or some sort of cache hence there is no easy way to determine if service restart is necessary after file replacement. Safe bet in most of the cases, is to perform a K2 service restart.

Just decided it is worth taking a note of this and share with other people who may potentially have similar questions.


Scripts for taking K2 service memory dumps

I’ve spent some time today improving “create K2 service memory dump script” (one which I already mentioned in “K2 MSMQ thread & MSMQ abort exception” blog post) and creating “collect dump support files”. Next step will be merging them into one and adding some nice to have things I have no time for right now.

Collect dump support files script (GitHub link):

Take K2 service process dump (GitHub link):

Be sure checking out GitHub links as I keep editing/updating these scripts there.


K2 MSMQ thread & MSMQ abort exception

There is one interesting fix included into K2 4.7 May CU which, as far as I know, is not mentioned in related KBs for some reason (KB001888 and  FP KBs). I just wanted to share some information about it as it may be useful for those who run older versions of K2 preceding to 4.7 May CU and additionally mention how to take K2 process memory dump conveniently.
First things first – the issue and related background information. Within K2 process there is a single thread which checks message queue, it is single thread and it process messages one by one (this is by design, as doing in a multi thread fashion is not necessarily best idea). Exception may occur in the process of message bus message processing and this dedicated K2 thread tries to abort this transaction to perform a retry which normally works just fine, but in rare scenarios MSMQ can throw another exception which causes K2 MSMQ processing thread to stop completely.
On the surface symptoms of this issue: suddenly your K2 users no longer receive any K2 task notifications at all, despite the fact that all relevant settings had not been changed and absolutely correct. Brand new test process confirms that task notifications do not work indeed for all usres while Email Events keep working fine. Quick fix/corrective action: restart K2 service – and all delayed task notifications should be gradually dispatched (depending on how long time ago MSMQ thread stopped, your delay for processing the piled queue may be quite big). Service restart resolves this because K2 starts MSMQ thread on service start up.
Good news is that 4.7 May CU has fix for this built in and when transaction abort is necessary MSMQ thread first checks if transaction in question is not already rollback/committed or completed status and only if this is not the case attempts to abort it. If even then K2 receives an exception then message moved into error queue.
I can imagine that when you run K2 version without this fix in production you may be reluctant to restart K2 service not being 99% sure that you deal with this specific issue, and there is a way to do that. To verify that your MSMQ thread within K2 process is still running you may follow these steps:
1) Take full memory dump of K2 process – for quick check on K2 threads either dump taken from Task Manager or procdump.exe will suffice.

In task manager you just have to locate K2HostSerever.exe from the list of processes, right click on it and select “Create dump file”, like that:

It will show you pop up indicated where dump file has been created once done, something like that:

Things gets more tricky with procdump.exe as you now need to obtain process PID, but it is way more configurable and allows you do more things when it comes to taking process memory dumps. As I work in support I really don’t like to repeat explanations on how to use it and where do I find PID and why PID is not displayed in my Task Manager and so on. So I created this tiny script for that (get it on GitHub):

2) Once dump is taken open it using DebugDiag and search for MSMQ, if MSMQ thread is running you should be able to find something like this:

If you unable to find this in memory dump of your running K2 process it most likely means that MSMQ thread had been stopped due to exception, and if you look under the Previous .NET Exceptions Report (Exceptions in all .NET Heaps) section, you most likely may see the aborted exception with MSMQ stack there.

On a side note DebugDiag also allows you to see if call which failed was made from K2 WorfkflowServer namespace or from something custom/external – that is also very useful to check in the very beginning of troubleshooting process.

I hope you may find this information useful and interesting for one reason or another 🙂 Stay tuned for new posts.


SharePoint 2010: Unable to edit user properties

The other day I received a support case where customer complained that they “suddenly” lost ability to edit user properties in SharePoint 2010. As usual picture worth thousand works so the problem was that if you navigate to Site Actions > Site Permissions, locate some user and click on your user name you will be presented with user information page and if you click edit you will see this:

Sort of interesting Edit Personal Settings dialog where it is not possible to edit anything…

But it used to look like that:

You see more properties listed and they are editable. Now having that description you have to be really skillful with art of googling to get to the bottom of this in the form of some blog post similar to this one. Because to do a proper Google search (one which yields a solution) you have to employ the right terms/know the nature of this issue. But if you noticed word suddenly in quotes in the very beginning I had a background information on preceding changes which caused this “sudden” issue hence was able to fix it. I will go into detailed explanation below for the sake of knowledge sharing.

First of all 1st screenshot is normal for environments where UPS is up and running – as soon as you configure it, SharePoint assumes that all property modifications are being performed on AD DS side and synced from there on a regular basis by UPS. Once UPS is provisioned SP 2010 hides/modifies default forms (layouts/userdisp.aspx – the one where you may click Edit Item to change your properties on the _layouts/useredit.aspx form) and instead of them for users whose profiles are synced you supposed to see specific user profile page instead, which will look approximately like this:

If it does not shown and you see the same uneditable edit form as on the first screenshot, then it either means that UPA is not configured completely or user profile is not synced yet (are you sure that user in question is in right OU?)

So essentially first screenshot/problem shows us that UPS was partially configured/profile(s) not synced (as we still not getting user profile page) but default forms already modified in the process of UPS installation, because when you provision a UPA it will set the fields in hidden site user info list to read only and hidden. With this knowledge about the nature of the problem you may google for the right scripts/information.

In my case we worked on environment where UPS was failing to start/work properly (one of these cases where you need delve deeper into configuration of UPS and peruse something like this blog post) hence it was just mandatory to restore ability to edit user properties. And for that you just need to use the script below against your SP web app (grab this script on GitHub).

Once this script completes you will get your editable user properties back. Two potential problems you may have with this:
1) If Get-SPWeb part of the script complains about incompatibility saying something like “Microsoft SharePoint is not supported with version 4.0.30319.34014” just run new PS instance using -version 2.0 switch;
2) If script completes successfully but you getting user profile page instead of your old beloved form – delete user profile and try again (in case you are not keen or fully removing UPA).

And one last note with regards how we run into this in my specific support case. Client was using K2 and they lived quite happily without UPS provisioned in their SharePoint environment which is a bit strange as a UPS is a requirement for K2. But after upgrading to 4.6.11 the very strange issue crop up which had a bit obscure symptoms on the surface, but in the end was isolated to the fact that each time GetUserGroups URM call was performed to the SharePoint provider no SharePoint groups of which this user is direct member were returned. On the surface it looked like random losing of user’s group membership information and randomly failed K2 tasks which were assigned to SharePoint groups. Randomness stemmed from the fact that GetGroupUsers URM call returned all users for the same group just fine.

And knowing that sometimes it is difficult to find where it was told that XYZ is requirement for K2, I’ll clarify this for UPS specifically: you can find it in K2 blackpearl Installation and Configuration Guide > Prerequisites > Environment Configuration > SharePoint Server 2010 User Profile Service set up

“The SharePoint User Profile Service on any non SharePoint Foundation version must be set up correctly for the Identity Services Group Providers to function correctly with regards to User, Group and Membership resolution. It must be correctly populated with the user’s information and the service must be started.”

Posting rather a lot about SharePoint 2010 at the time of 2016 and cloud stuff I rather feel like author of The Old New Thing blog who at some point decided to blog about old stuff as there is less competition there – everybody busy blogging about new and shiny things (though I should admit I don’t go into really low level details as that blog does) 🙂 But I hope these posts may still be useful for someone.


How to: configure K2 NLB port rules with PowerShell

Long time ago I did a video and blog post on configuring Windows NLB K2 cluster. I know that those materials are not perfect, but thanks to blogging you not only can be subject of mockeries for mistakes and naivety in your old posts, but also you can review and improve on them over time 🙂

Anyhow my old blog post on creating K2 NLB cluster contained this neat picture of required port rules:

As I tread my test K2 environments as “wipe and load”-ready and subject them to all sort of experiments leading to wipe and load and rebuilds I grow tired of creating this rules via GUI. Thanks to PowerShell and Microsoft Community it is not a problem to find a sample script to create Windows NLB cluster. I actually wanted to rewrite it with minor improvements and K2 specifics to spin off K2 NLB cluster quicker but due to endless lack of time this idea moved on the back-burner. What I did instead though is prepared PS script to create port rules:

That’s help a bit when I rebuilding my test environment. You can grab this script from GitHub too.


How to: Install SharePoint 2010 August 2015 CU

On a day to day basis I keep repeating people to always check on with K2 compatibility matrix before installing or upgrading their K2 environments. Very frequently people try to mix K2 with too new Microsoft components which weren’t tested with their version of K2. But there is an opposite issue when Microsoft infrastructure components lag behind in terms of patches/versions fully supported by their release of K2. I know quite a few people still using SharePoint 2010 with K2 4.6.11. So with SharePoint 2010 being an old thing in itself people often skip CUs for this product for some reason which is unknown to me. In this article I want to discuss what is the latest CU for SP 2010 supported by K2 4.6.11 (note that with 4.7 K2 dropped support for SP 2010) and how to install it.

What is the latest CU for SP 2010 supported by K2 4.6.11? As usual you have to check compatibility matrix, but you have to find old one, which will show you this:

And this:

Does it mean that newer CUs will break something/won’t work with K2? Not necessarily, it only means that it won’t be supported because it has not been tested. At the time of release of 4.6.11 latest SP 2010 CU available was August 2015 CU and hence all testing and QA was performed against this CU – K2 cannot guarantee that all will work with newer CUs.

With that knowledge if you are still on SP 2010 it makes sense to make sure you running “newest” supported CU for it. Easiest way to do that is fire off SharePoint Management Shell on your SharePoint server and execute the following command:

This will give you your current build:

Having this information look up in SP builds list @ Todd Klindt’s SharePoint Admin Blog to translate this into CU and SP levels, for example 15.0.7106.5000 translates into August 2013 CU:

Note that there may be minor last digit discrepancies depending on how you look up for build number. So now I know that my SP 2010 is August 2013 CU and for K2 4.6.11 I can go up to August 2015 CU (download link) from that – let’s try to do it.

First things should go first – backup your SharePoint environment. Navigate to Central Administration > Backup and Restore and click Perform a backup – just go through the wizard and create full farm backup. It can be good idea to test that your backup can be restored.

Once backup is done an CU file is downloaded launch it, accept license terms and hit “Continue”:

CU installer will check for installed updates and proceed with extracting files and installation of update after that:

Once done it will ask for reboot:

Most frequent mistake in all this process it assuming that after reboot of your SharePoint server you will be running updated SharePoint version. Quick check with (Get-SPFarm).BuilVersion will show you the same build as it was before you started CU installation process. So update is not finished just yet and to complete it you have to locate SharePoint 2010 Products Configuration Wizard in Start Menu:

and run it. Next you just go through the wizard’s steps to complete upgrade:

Warning you got in the very beginning should be taken seriously if you do this on a server used by other people where IIS reset may have undesired impact:

Once all configuration tasks completed you should get confirmation of successful configuration and click Finish button:

After clicking on Finish it will take you to CA main page automatically. In CA you can navigate to Upgrade and Migration > Upgrade Status where you can see confirmation of successful upgrade:

And now it is time to issue (Get-SPFarm).BuildVersion command once again:

First execution of the command on the screenshot was made before running of SharePoint 2010 Products Configuration Wizard and the second after wizard completion – now we run build 14.0.7155.5000 which is the latest SharePoint 2010 build officially supported by K2 4.6.11.


Freshly installed K2 – unable to access K2 workspace with HTTP Error 401.2

I’ve recently did some quick and dirty installation of K2 4.6.11 on Server 2008 (non R2) hence all you have there is PoSh 2.0 it is not possible to use amazing K2Field.PreReq script to take care about all the prerequisites (it will work for server 2012-2016). So I just went ahead and tried to satisfy complaints from K2 blakcpearl setup manager as I go adding IIS along with KB980368 as indicated by Setup Manager. Alas after installing I was not able to access K2 Workspace with the following error:

“You are not authorized to view this page due to invalid authentication headers.” Why? Quick check of K2 Workspace site authentication showed that Windows Authentication is missing, while according to K2 documentation (sourceK2 Workspace does not function if IIS is not configured correctly. Configure the IIS application pool Managed Pipeline mode setting to Classic and ensure that:  

  • Windows Authentication is enabled
  • Anonymous authentication is disabled

So I just went ahead and added Windows Authentication role service and all started work correctly after this. It tells us that: A) K2 setup manager created site config file correctly specifying required authentication method, it just was not installed/available B) Not sure why K2 Setup Manager does not have built-in check to flag this at the installation stage. C) Read up documentation carefully, in this case this page.


How to: enable Document Set in Document Library

I just recently bumped in into this thing – you have to enable Document Sets on a library level before you can actually use it. This little point baffled me a bit when I tried to use Create Document Set SmartWizard in K2 Studio:

It took me a while to switch over too my SharePoint document library to realize that I just can’t create document set there:

Normally the same New Document menu contains an option to create Document Set. Well now it’s clear that “Required field is empty” error is just a clumsy way employed by K2 Studio to tell you that Document Sets disabled for your library.

To enable them you just go to Library Settings > Advanced Settings > Allow management of content types as on screenshots below.

Click on Library Settings button on ribbon:

Click on Advanced Settings:

In advanced settings select Yes for Allow management of content types and hit OK:

Now you also need add Document Set content type using Add from existing site content types link in library settings:

At this point you should be able create document sets in SharePoint just fine:

Yet you still going to have problem with K2 SmarWizard I mentioned initially. Why? Just go to K2 App settings for your library to see the answer:

Just click on Regenerate SmartObjects, go back to K2 Studio and Create Document Set SmartWizard to see things working there:

Voila, we can now see our Document Set enabled library and use SmartWizard to create document sets in it.

Just to recap: To be able to create document sets within SharePoint libraries you have to Allow management of content types in Advanced Settings of this library and add Document Site content type using “Add from existing site content types” link in library settings.


Curious case of stubborn Workgroup flag

I’ve just recently got a support case from the client where no matter that we tried MSMQ won’t work in Directory Service Integration mode, resulting in the following warning from K2 blackpearl Setup Manager:

MSMQ component is a prerequisite for K2 and it seems that all you need to do covered in K2 documentation: Installation and Configuration Guide > Prepare > Supporting Components Configuration > Message Queuing (MSMQ)As an example of functionality which will be impacted by this issue I can mention task notification emails as those have to be queued in MSMQ before being picked up by the Eventbus.

Yet information there was not sufficient, and required me to do some prolonged troubleshooting and googling. But the thing is that MSFT documentation does not highlight root cause which I found either and only some old obscure blog post lead me in the right direction.

So according to K2 documentation we have at the moment we supposed to set permissions and instead of outlining what permissions to set and where, KB strangely starts from where to set them, omitting WHAT & WHY parts 🙂 Moreover it suggests to set permissions on what its called “root object” and according to KB documentation means MSMQ container itself:

But this is not possible at all – this Root Object does not exist before you installed MSMQ Directory Integration Service, and if was installed correctly there is no need for you to go and set any permissions. But if it was installed but not in Directory Integration mode it won’t have its properties exposed in AD:

For WHAT & WHY parts K2 documentation elegantly refers you to MSFT TechNet. There you have to navigate and do a bit of careful reading to find out that setting permissions in AD DS required before installing Directory Service Integration Features of Message Queuing (why not start with this in K2 documentation?).

MSFT KB says that special permissions have to be set IF you installing Directory Service Integration feature of Message Queuing on a domain controller (we can safely ignore this as we need to install feature on K2 server and we won’t be installing K2 on domain controller, except for “all-in-one” test box scenario). Next MSFT KB says that you have to grant the Network Service account the Create MSMQ Configuration Objects permission to the computer object in AD DS before installing the Directory Services Integration feature on a computer that is a domain controller. So all in all according to MSFT KB you only need to set permissions in case you installing MSMQ Directory integration on DC. So no need for extra permissions, right? There are some required permissions but normally they are in place by default.

To save you pain making sense of all this documentation you have to mess with permissions only when installing MSMQ on domain controller, period. But recently I had a support case where this just does not want to work and after unsuccessful troubleshooting attempts with client I revert to my test lab and run into the same issue there. The fact that I run into it only on one server tells me that it only happens if your computer ACL was somehow customized or locked down either intentionally or not. If that pesky Workgroup flag keeps reverting to 1 despite you installed Directory Service Integration Feature, please make sure that SELF identity has the following rights on your K2/MSMQ server in AD:

So in short K2 KB should be structured like that:

1. K2 requires MSMQ Server and MSMQ Directory Service Integration components to be installed. DS integration improves security as it enables publishing queue properties to AD, authentication and encryption of messages using certificates registered in the directory.

2. Before installing MSMQ on domain controller machine you may need to grant additional permissions as described in Microsoft documentation:

NOTE: this is only applicable for “all-in-one” test servers where you may want K2 to coexist on the same machine with DC. This is not applicable for production deployments where K2 runs on the dedicated AD DS member server.

3. In case you doing normal installation on AD DS member server you usually do not have to grant any special permissions except for if you security ACL for K2 server is customized. If you installed MSMQ Directory Service integration on domain member server and Workgroup flag reverting to 1 all the time then check that SELF identity has Create MSMQ Configuration objects and Delete MSMQ Configuration objects rights granted over your K2 server computer object:

NOTE: (1) My tests show me that it is sufficient to apply these permissions to “This objects only”, but you should understand that enabling disabling Directory Service Integration feature requires restart of the machine, so it seems it is all about rights at the point of installation and first reboot after it to create MSMQ objects correctly – I noticed that if I delete MSMQ objects, revoke rights and even reboot the machine Workgroup flag keep staying set to 0, but reinstalling MSMQ feature reveals this problem again. Granting rights sometimes work on the fly without reinstalling MSMQ – just restart the service.

(2) These advanced permissions may become messy way to quickly as you inherit them from your domain and then each time you click on Add button separate ACL entry is being created for your computer object, so watch out for explicit Deny settings overriding your Allow grants.

(3) As usual monitor Administrative Events view in Event Viewer and watch out for MSMQ related errors – it should be able to tell you what’s wrong.

4. When installing K2 on standalone servers (not joined to domain) or in cases when you unable to make Directory Service Integration work you can consider using workgroup mode and private queues. Though if latter is the case it is much better investigate and resolve your Directory Service Integration issue.

Apart from possibility of better structured related information in K2 documentation I’m wondering why MSFT does not have full set of permissions required for Directory Service Integration mode published somewhere? It seems this issue with lacking rights for SELF identity does not happen as by default in Windows Server 2012 R2 domain on newly provisioned server its ACL entry looks as follows:

Hope this article will save someone some time which may be wasted on troubleshooting this.

UPDATE: And as for original support case, there issue persisted even after we granted all required rights to SELF object. At this point we identified that MSMQ logs the following error with code 0xc00e050f, which indicated that MsmqServices object was missing in client’s AD DS domain Configuration partition (though to find this out it was necessary to read some forum t thread created 13 years ago and relevant for Windows Server 2003 🙂 ). Here is the steps how to verify its presence and correct this if necessary:

1.Run ADSIEdit

2. Expand the the configuration container, then expand Services. Check whether MsmqServices object and the regular MSMQ object are there

3. If the MsmqServices object is missing, right-click on Services and select “New Object”. For the object type, select mSMQEnterpriseSettings, for the object name use MsmqServices

4. Save the changes and close ADSIEdit, and force AD DS replication to avoid situation when machine where MSMQ is being installed queries some other DC than the one where you made this modification

5. Retry the MSMQ installation, it should now succeed.