Configuration reference

DocView Capture has two kinds of settings:

• Start-up settings that each program needs before it can reach the database: the connection string, storage, the key ring certificate and so on. They are described on this page.
• Administrator settings that are changed while the system runs, such as retention periods and session rules. They are stored in the database and edited in the app. See Settings.

Where start-up settings live

Example appsettings.Production.json for a web app:

{
  "ConnectionStrings": {
    "DocViewCapture": "Server=SQL01;Database=DocViewCapture;Integrated Security=True;Encrypt=True;TrustServerCertificate=True"
  },
  "Storage": {
    "Provider": "FileSystem",
    "RootPath": "\\\\fileserver\\DocViewCapture\\Storage"
  },
  "DataProtection": { "CertificateThumbprint": "<thumbprint>" },
  "Authentication": { "Windows": { "Enabled": true } },
  "ReverseProxy": { "Enabled": false }
}

After you change a file, restart the site or service.

Settings table

The Web and DocView Worker columns show which program reads the setting.

Important: Remove Bootstrap:AdminPassword after the first start. It is only used to create the first administrator. The IIS install script removes it for you; on Azure, delete the Bootstrap__AdminPassword application setting.

Storage and several servers

Every web server and DocView Worker must see the same storage and database:

• on premises, set Storage:RootPath to a file share that every application account can modify;
• or use cloud storage: Storage:Provider set to AzureBlob, S3 or GoogleCloudStorage.

With more than one server, every server must also use the same key ring certificate (DataProtection:CertificateThumbprint, or CertificatePath and CertificatePassword). Without it, secrets encrypted on one server cannot be read on another. See Install on IIS and Install on Azure.

Database upgrades managed by DBAs

By default the programs upgrade the database schema themselves at start-up, which needs db_owner rights. If your DBAs apply schema changes themselves:

1. Set "Database": { "InitializeOnStartup": false } in both programs' settings.
2. Before each upgrade, run the release's DocViewCapture-Database-<version>.sql. It is safe to run more than once. When DocView has its own schema (Database:Schema), use the script written for that schema (DocViewCapture-Database-<version>-<schema>.sql; ask for it, or build the release with -DatabaseSchemas <schema>).
3. The application accounts then only need db_datareader, db_datawriter and EXECUTE.

Docker variables

docker-compose.yml reads these variables from a .env file:

Note: Without a certificate, containers store the key ring keys unprotected and log a warning. Always set a certificate in production.

Health endpoints

Both programs answer, without sign-in:

Use them for load balancer probes and monitoring. The DocView Worker answers on the address in Kestrel:Endpoints:Health:Url.

Related pages

• Settings
• Install on IIS
• Install on Azure
• Troubleshooting