Error during 5.5 clean install > XML parsing: line 575, character 209, semicolon expected

  • 23 August 2021
  • 9 replies
  • 22 views

We are moving our K2 on-premises server to another server. So, instead of installing 5.4, which is what we are currently on, I chose to install K2 5.5 fresh.

 

During the install we failed with this error:

 

19379i7742A2463F7D5E4F.png

 

Do we need another installer deployed with a fix for "SourceCode.Data.SmartBroker.inject.sql" ??

 

Does anyone have any tips or can help? Thanks.


9 replies

The installer we used is K2 Five (5.5) (5.0006.1000.0).exe


 


 The error we see while installing

So we went back through the instructions and applied Azure SQL DAC pack here: https://help.nintex.com/en-US/K2blackpearl/ICG/current/default.htm#Install/AzureSQL/AzureSQL_BP.htm


 


Then we went back through the clean install of 5.5 and now have this:



 


Which leads to this https://community.nintex.com/t5/Technical-Issues/Powershell-Commands-to-Encrypt-and-Decrypt-Data/ta-p/123784


 


However, the instructions say this, "SQL Azure does not support this method so you can only use the PowerShell commands in this article with on-premises SQL servers."


 


But Azure SQL also has default data encryption on by default:



 


So now what? Should I get Nintex professional services to help now?


 


 


 

https://help.nintex.com/en-US/platform/ReleaseNotes/K2Five.htm looks like we have to find 5.0005.1000.4 installer to fix this issue

Hi


 


5.0005.1000.4 is K2 Five 5.4 installer. Do you have an open Nintex case for this?


 


Thanks


Vernon


 

NOPE



 

I'm going to file a ticket now. and 5.4.4 was not the solution. 

Hi Fred,


 


Did you find a solution to this issue? , I facing the same.

We gave up on running K2 on SQL server Azure.


 


Our consultant said she never has luck running it this way and the true work around would be to temporarily stand up a Windows VM in Azure and do the K2 install with the K2 DAC agent in that Azure VM. After the install, tear down the DAC VM.


 


So we went back to on-premises SQL server. Shame, because it would have been nice to reduce our infrastructure and costs with an Azure SQL server.

Reply