In recent versions of K2 installer team introduced a feature which blocks installation in case of critical failure leaving you no choice but address the issue and perform repair. It basically blocks all the other options leaving you with Recover as an only available option as shown below:
This option is here for a reason and unless you 100% sure that you need to exit out of this mode you should analyze error and perform repair, if necessary involving vendor support. But in case of throw away test box or initial installation you may want to unblock all the other option, let’s say to perform removal and start from scratch. To do that you just need to delete contents of the Setup State folder (default location is “C:\Program Files\K2\Setup\State”) which in this case will contain json files with the state of failed installation. Those files contain sections like “ComponentActions”, “FailedTarget”, “CompletedTargets”, but to the best of my knowledge support will ask you for installer trace to investigate any type of installer failures.
Like I said in case you understand what you are doing and need to exit out of “Recover” mode you can just use folder clear up approach explained above.
Although my keep steep drop in amount of K2 posts from my side with more than high probability in the future, I’m keep jotting little things for now. The other day I was a bit perplexed by K2 Platform Classic setup manager which blocked me from adjusting K2 service account like that:
What it actually does is forcing you to use currently logged in user. And addressing why part it happens when you have developer license – in that case setup manager forces you to use currently logged in user as a “service” account (remember that Developer license requires you to run your K2 service in a window within interactive user session). Just though it may be useful to write this down and share.
When you run current versions of K2 Setup Manager it saves trace file in %temp%\K2 Setup Log directory and you may also find trace files in your K2 installation directory in Setup\Log subfolder. Trace files which you can find there named InstallerTraceDDMMYYY_N.log. Quite often it is necessary to confirm what mode (Install, Upgrade, Configure, Repair) was selected during last run of K2 Setup Manager. To do that based on installer trace you need to search trace files entries containing this string:
Last entry will tell you selected mode – Configure, Install etc.
Hopefully this tip can save you some time or clarify doubts on what action was selected during last run of K2 Setup Manager.
Once in a while you can bump into a warning from K2 Setup Manager which says: “The selected user needs to have Domain Users privileges to proceed” on K2 Site Application Pool Configuration which looks as shown below:
I was not able to confirm what exactly triggers this, but I do know that it happens while specified user in fact has Domain User group membership and I saw it with both K2 4.6.x and K2 Five installers. Good news that bypass this blocking warning is easy – you just need to edit Product.config file in your installation directory and set domainusercheck value to false as shown below:
You will need to restart K2 Setup Manager after saving this change and you should be able to proceed without receiving any any warnings.
So with new wave of releases from Microsoft we now have Visual Studio 2015 and Windows 10 amongst other things, and depending on what you do you may be more excited about one or another of these two. But what is common between VS 2015 and Windows 10 they all come with .NET 4.6. There is much more in these new versions, but for example for Windows 10 two salient features you will notice are built in .NET 4.6 and Edge browser.
Now to K2. Upcoming 4.6.11 release promises us full support of Windows 10 (excluding Edge browser), but there is an interesting thing with old versions of K2 and .NET 4.6. In case you are doing development for older versions of K2 platform you may want to use Windows 10 and/or Visual Studio 2015 on your development workstation and this may pose a small issue.
Here is screenshot from clean Windows 8.1 Enterprise machine on which Visual Studio 2015 installed. This is what we have in terms of .NET on this machine:
As you can see we have .NET 4.5 as well as .NET 4.6 installed. But here is what K2 Setup Manager 4.6.8 thinks about this:
So you don’t have .NET Framework 4.5 🙂 Some other applications may have issues with detecting your .NET version with advent of 4.6, but as Microsoft says in such cases “if app was written accordingly to our recommendations you won’t have any issues.” You may read up a bit about this in the related blog post at Aaron Stebner’s WebLog.
No worries – you will see this only with 4.6.8 and earlier versions, starting from 4.6.9 and onwards .NET detection works OK whether you have .NET 4.6 or not. You may also contact K2 support to obtain a coldfix for K2 setup manager 4.6.8 which will will solve this issue.