This was a really weird one. A client’s application suddenly suffered from this error in all environments simultaneously. The root cause had nothing at all to do with K2 blackpearl, but it affected the service keys of the instance of a service, which brought down the service and caused the exception.
As I was walking our business users through the role management features of the K2 Workspace, they lamented that they K2 didn’t give them visibility inside of the Active Directory groups which are assigned to various roles. My quick solution was to provide them with a PowerShell script which would give them the insight they were looking for.
That’s a stupid slug. Oh well. Moving on…
How can you tell what people have been assigned to a particular AD group?
We’ve sent a request to security to delete an security group and to create a new one. The ticket is completed, but I can’t assign the new group to a role in K2 because I can’t see the new group. What I can see, though, is the old group name when I search for the new group. What gives?
One element of managing workflows through the K2 Workspace that has always been a little tricky has been the addition of users to a role. There are some details about it which seem to me to be easy to miss. I’d like to help with that. Continue reading