I have this Issue, I am getting this Exception on K2 :
Type 'Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException' in Assembly 'Microsoft.IdentityModel.Clients.ActiveDirectory', Version=3.10.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 is not marked as serializable.
Not entirely sure, i came across a ticket with the same error as you, but it was workflow related with an email step. It could be that your that proxy is blocking trust.k2.com (This is what the inner exception showed of the ticket). The resolution for the ticket were to update the Exchange connection strings to use the correct OAuth Resource, and to adjust the internet options configuration. If this does not help, I recommend opening a support ticket.
Not entirely sure, i came across a ticket with the same error as you, but it was workflow related with an email step. It could be that your that proxy is blocking trust.k2.com (This is what the inner exception showed of the ticket). The resolution for the ticket were to update the Exchange connection strings to use the correct OAuth Resource, and to adjust the internet options configuration. If this does not help, I recommend opening a support ticket.
Kind Regards
Prineel
Many thanks, Can you kindly assist with screenshots? Let me see if I could do the same.
Unfortuanately there are no steps on how the fix was implemented. You will need to open a support ticket for assistance. This is all I could find from the ticket:
Kind Regards
Prineel
Hi Everyone
Has anyone ever find a solution to this issue. I’m having the similar issue with 'Microsoft.IdentityModel.Clients.ActiveDirectory.AdalServiceException' Assembly is not marked as serializable.
I’ve open a ticket with Nintex, they couldn’t find the problem. They suggested it could be the network routing issue.
I’ve added ‘trust.k2.com’ to the proxy bypass but workflows instances still get stuck in error.
Any help or suggestion is welcome.
Thanks.
We ran into this issue this week and believe the cause being a self-signed SSL cert (issued by the K2 installer) that was only issued to be valid for a SINGLE year… This looks like an issue in the 5.5 RTM installer - we had a look at the Cert Manager for 5.6 and it issues 10 year certificates so it seems to have been discovered as an issue.
In order to correct the issue, we had to recreate the Exchange feature. Updating the one that worked previously did not work and gave an error.
After adding a new feature and updated the name of the feature in the Exchange connection string in the ConnectionStringEditor, email worked again.
Nintex support was not very helpful so do not expect miracles. It is a shame that they say that the issue is environmental when it was their cert that expired that caused the issue with the Exchange feature and the client is left to deal with fixing it.