Upgrade from 3.7.x to 3.8.x
Version 3.8.x introduces the following new functionality:
Better support for EzeScan Cloud.
User defined values for user profiles.
Consolidated auxiliary databases into single storage database.
Remote Indexing Assistant (RIA) indexed items recycle bin.
Digital Forms Assistant (DFA) history events.
Digital Forms Assistant (DFA) client side saving of saved form tokens.
Digital Forms Assistant (DFA) ability to email saved from tokens.
Upgrade Steps
If you require assistance upgrading your installation then please reach out to our support team.
Stop IIS application pool.
Backup databases in SQL Server Management Studio.
Backup your EzeScan WebApps installation files.
Record any customisations applied to the web.config file.
Remove all files except App_Data and appsettings.json
Copy 3.8.x installation files into EzeScan WebApps directory.
Rename your existing appsettings.json file to appsettings.3.7.json.
Copy the appsettings.template.json file to appsettings.json.
Compare the old appsettings.3.7.json file to appsettings.json and remove underscores from any commented out entries that were in use on the old configuration.
You may also need to update the connection strings if you’re MS SQL server is located on a separate server.
Remove the underscore from the “storage” node. (This will trigger EWA to create the storage database on first run and migrate data from SQLite databases to the new MS SQL database.)
Reapply any customisations to the web.config file.
Start IIS application pool and navigate to the site.
Check the log file for any error messages between the
"EzeScan WebApps Starting"and"Application started. Press Ctrl+C to shut down."log entries.Confirm the storage database has been created and is in use by clicking the databases panel on the admin dashboard.
Why have the connection strings changed?
Due to underlying updates in the Microsoft SQL packages used by EzeScan WebApps encrypted communication to the database server is now enabled by default.
If your database server doesn’t have a certificate signed by a trusted CA (e.g. using the default built in self signed cert) then your connection strings will need to force your server to trust the database servers certificate.
If your IIS server doesn’t trust your database servers certificate you will see a log entry like: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.
This can be achieved by adding the following setting to the end of the connection strings:
TrustServerCertificate=True
So for example the following connection string:
Server=.\\SQLEXPRESS;Database=ezescan.webapps.indexing.event;Integrated Security=true;
Would become:
Server=.\\SQLEXPRESS;Database=ezescan.webapps.indexing.event;Integrated Security=true;TrustServerCertificate=True;
If your MS SQL installation runs on the same server as IIS then the above solution is perfectly acceptable as network traffic is never leaving the box and is therefor not susceptible to man in the middle attacks.
If you are using MS SQL hosted on a separate server then the recommended approach is to configure the MS SQL Server with a valid certificate that is trusted by the IIS host.