When your license has expired, it would be great if you have the ability to update this via the K2 Management UI instead of having to run this via the K2 Configuration Manager or updating it directly in the K2 Database.

Below it would be better for users if it said:

Expired License

Your license has expired, please enter your new license key that you have received from portal.k2.com

Enter your new license key: xxxxxxxxx

[Update Button]

With it pre-populating the machine key, it would make it easier than the current system of having to reach out to a K2 support representative.

Currently the K2 Webservice Endpoint broker does not support Security Username Token authentication; at the moment this is only implemented for WCF Endpoint broker.

With the WCF Endpoint broker, once successfully configured and registered, you have to pass in the username token every time you execute a SmO method against the registered service -- sure, you can put this in a variable field or maybe even an environment filed but this is very static in nature. In other words if or when you change the password information for the underlying service account you will need to update the serialized complex string value with the updated username token value across multiple solutions i.e. workflows forms, views, etc. This can be painstaking in larger implementations.
For this kind of scenarios there should be an option to allow this to flow down from the service instance level similar to the "Default HTTP Request Headers" service key.

So, this is a two part feature request:

1. Support for Security Username Token authentication with the Webservice Endpoint broker

2. Option for a "Default Security Username Token" service key in the service instance configuration.

With the introduction of the "Recover" option in the K2 Installer, there are some very rare instances where recovery may not be possible, which causes the installer to be stuck in a "limbo" state of not being able to revert/proceed with the upgrade.

(Say for example you have a new server and no "checkpoint" is available to revert back to/you need to make changes to the K2 Service Account credentials due to a special characters being in the Service Account Name/Password that has the potential to break the installation or another example is that something goes wrong with a production upgrade - you have to log a ticket because for whatever reason the installer is failing and you cannot recover it yourself, which results in down time and potential loss of servive).

It would be useful if we could at least implement the following:

1. On clean install - remove K2 Five 5.4 completely
2. Allow users to run through the K2 Setup Manager "reconfigure" screens in case they need to update anything to allow them to recover
3. Possibly a very complicated suggestion, but it would be amazing if we could allow people to roll-back/revert to a "previous" K2 version
4. Easily revert FP's or CU's without having to uninstall K2

This is with respect to setting up the K2 Database for automatic failover via the SQL Always on feature:

https://help.k2.com/kb001572

In a scenario where both the primary and secondary replica are in different subnets we will configure the listener to have two IP addresses, one for each subnet. However, due to SQL configuration, once we failover to the secondary replica and need to hit secondary subnet, we will hit the SQL Availability group listener and try the subnet IPs configured for the listener in a serial manner. This causes the K2 product to run into connection timeout issues after a failover has occurred. Adding the MultiSubnet=True to the SQL connection string on K2 can resolve this and allow the connection to hit both of the IPs in parallel instead so we do not hit a connection timeout error. Per this MS Documentation (https://docs.microsoft.com/en-us/sql/relational-databases/native-client/features/sql-server-native-client-support-for-high-availability-disaster-recovery) . At this time in K2 we can add this parameter, but it requires modification of K2 Config files and can be easily overwritten by an upgrade or reconfigure. Request here is to make this a supported and configurable addition to how K2 product connects to it's SQL Database.