primedocs Server Installation
ℹ️ Info This page concerns the OnPremises option.
With the "Software as a Service" option, no server installations by the customer are necessary.
Before you start:
Prerequisite for the installation of the primedocs server is a Microsoft SQL Server database to store the data. If you cannot use an existing database server, you can perform a SQL Express installation as described here. The correct configuration of the SQL user for primedocs is described here.
Would you like to update an existing installation?
To update an existing primedocs server, follow these instructions here.
Installation
The installation package contains a PowerShell script "Install.ps1" that performs the installation. The script must be run as administrator because, among other things, missing Windows features are activated.
NOTE
The installation script ("Install.ps1") is designed to install exactly one primedocs environment on one server. If multiple primedocs environments are to run on the same server, then additional manual configuration steps are required. See Multiple In-Process Applications in same Process on the Troubleshooting page.
Run script
The installation zip file must be unpacked beforehand.
The Install.ps1 is signed and must be called with the installation arguments. These are described in the file in a large comment (under “Usages”).
Standard call (for this, you must first navigate to the installation directory, e.g. with cd "C:\temp\primedocs_Install_Package"):
.\Install.ps1 `
-HostUrl "https://your-url.local" `
-DbConnectionString "Data Source=...;Initial Catalog=primedocs_Prod;User ID=...;Password=...;MultipleActiveResultSets=True" `
-OperationDbConnectionString "Data Source=...;Initial Catalog=primedocs_Prod_Operation;User ID=...;Password=...;MultipleActiveResultSets=True"
Further call options are described in "Install.ps1" in "Usages", e.g. the specification of a service account, if no SQL user is to be used.
The two databases from the above example ("primedocs_Prod" and "primedocs_Prod_Operation") can either already exist as empty databases. Otherwise they will be created automatically by the primedocs server applications (for conditions see SQL server roles / permissions).
NOTE
When installing the "WithoutIdS" option (see Varianten), no OperationDbConnectionString is needed.
By default, the script asks the user for information and confirmations. If this is not desired, -Force $true can be supplied as an argument.
Script procedure
1. Check required Windows features
The first step is to verify that all required Windows features (including the Internet Information Service (IIS) with ASP.NET) are installed and that the hosting bundle for .NET 10 applications is installed.
2. "primedocs" website in IIS
The next step is to verify whether a "primedocs" website is already registered with its application pools in IIS. If this is the case, it will continue with the next step.
If the website is not found, you will be asked if it should be created, with the installation path and port specified. The default settings are displayed in the output. The script also creates the following application pools in IIS:
primedocs-Managed:
Responsible for the .NET Framework-based server applicationsprimedocs-Unmanaged-[...]:
For all server applications, a separate application pool is created, such asprimedocs-Unmanaged-AddressServicefor the "AddressService" orprimedocs-Unmanaged-HealthMonitorfor the "HealthMonitor".
The primedocs server applications run exclusively as a 64-bit process. The application pools must therefore run in 64-bit mode: "Enable 32-Bit Applications" must be False (IIS → Application Pools → [Pool] → Advanced Settings → Enable 32-Bit Applications = False). The installation script creates the pools correctly as 64-bit — only verify this setting when making manual changes.
Background: the server package ships its native dependencies (SQL client, image and document rendering) only as the x64 variant. They cannot be loaded in a 32-bit worker process.
3. "primedocs" web applications
In this step the actual web applications are put in the "primedocs" website. If the applications are already installed, you will be asked if an update should take place. In case of an update, we recommend contacting our support.
4. "primedocs JobHost" scheduled task
In the last step you are asked, whether the "primedocs JobHost" should be set up as a "scheduled task". The primedocs JobHost is a console program that updates user data in the background at a certain interval, for example. Therefore, it should be installed.
Completing the server installation
After the installation, both the IIS and the web applications and the scheduled task should be installed.
TIPP
In the default installation, a website is created that listens on port 80. If there are several websites running on the same server, this could lead to conflicts. In that case the primedocs website will not start.
Setting up the HTTPS binding
The installation script creates the "primedocs" website with an HTTP binding only (default port 80). A TLS/SSL certificate is mandatory for operation (see system requirements). Therefore, set up the HTTPS binding after the installation using standard IIS tooling:
1. Import the certificate
Import the TLS/SSL certificate including its private key (.pfx) into the computer's certificate store — either via the MMC ("Certificates (Local Computer)" → "Personal") or via PowerShell:
Import-PfxCertificate -FilePath "C:\temp\certificate.pfx" -CertStoreLocation Cert:\LocalMachine\My -Password (Read-Host -AsSecureString)
2. Add the HTTPS binding
In IIS Manager, under Sites → primedocs → Bindings → Add..., create a binding of type https on port 443, enter the host name (e.g. your-url.local) and select the imported certificate.
3. Optional: redirect HTTP to HTTPS
The HTTP binding (port 80) can then be removed. Alternatively, a redirect from HTTP to HTTPS can be set up, e.g. using the IIS URL Rewrite module.
The HostUrl specified during installation (https://...) must match the HTTPS binding so that the URLs stored in primedocs.config are reachable.
Service Account
The default installation assumes the use of an SQL user. However, it is also possible to run the primedocs server applications using a service account or a Group Managed Service Account. For this, ensure the following configuration:
- The service account can connect to the SQL Server or to the future database.
- The service account is a member of the https://docs.microsoft.com/en-us/iis/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis#understanding-the-new-iis_iusrs-group .
This step is done automatically by the installation script if a security account is specified when calling it via arguments (see "Usages" in "Install.ps1" file) and the corresponding query is confirmed.. - For the
IIS_IUSRSgroup,Log on as batchandImpersonate a client after authenticationmust be stored in the Local Security Policy (this corresponds to a standard IIS installation).
Administrative Tools → Local Security Policy → Local Policies → User Rights Assignment - The service account has modification rights on the primedocs application and log directory (in the default installation this is the same folder).
This step is automatically taken care of for the application directory by the installation script if a security account is specified when called via the arguments (see "Usages" in "Install.ps1" file) and the corresponding prompt for change rights is confirmed. - The service account must be stored in IIS as a user in all primedocs application pools.
IIS → Application Pools → Advanced Settings → Identity → Custom account
This step is done automatically by the installation script if a security account is specified when called via the arguments (see "Usages" in "Install.ps1" file).
ℹ️ Info When using a Group Managed Service Account (gMSA), the username must be specified in the format
domain\accountname$. When IIS detects that the username ends with a dollar sign ($), it automatically treats the account as a gMSA and disables the password field in the user interface, since no manual password is required for this account type.
- The service account must be stored as executing user in the "
primedocs.JobHost" task.
Task Scheduler → Task Scheduler Library → primedocs.JobHost → Properties
This step is done automatically by the installation script if a security account is specified in the call via the arguments (see "Usages" in "Install.ps1" file). - The service account is used in SQL-ConnectionString (passed as argument during installation or customize it in "primedocs.config"-file).
This step is done automatically by the installation script if the correct ConnectionString is specified in the call via the arguments (see "Usages" in "Install.ps1" file).
Read-only application directory
By default, primedocs requires write permissions in the application directory in order to:
- Managing ASP.NET Core DataProtection Keys
- Writing log files using
NLog - Importing and exporting data via the DataSourceAdminApp
To prevent write access to the application directory, make the following changes:
- In
primedocs.config,aspNetCoreDataProtectionDirectory="C:\Path\To\WritableFolder\"must be stored. This means that ASP.NET Core DataProtecion keys are no longer stored in the same folder as theprimedocs.config. - The
file-target in allNLog.configfiles must be changed and${baseDir}replaced with the corresponding folder path.- In
primedocs.config, thelogFilePathunderappsmust also be adjusted. However, this is only to enable the DataSourceAdminApp to read the log files.
- In
- In
primedocs.config, theworkingDirectoryPathattribute must be set for each entry underapps.
Important: The user executing the IIS applications or JobHost must have read, write, and modify permissions for this folder.
Example scenario:
All write operations should take place under D:\Apps\primedocs\.
Adjustment to NLog.config ("file"-target):
Please note: Each application requires its own folder or name!
<target name="file"
xsi:type="File"
layout="${layout}"
fileName="D:/Apps/primedocs/[DataSourceAdminApp/...]/serverApp.oolog"
createDirs ="true"
archiveFileName="D:/Apps/primedocs/[DataSourceAdminApp/...]/serverApp.{#}.oolog"
archiveEvery="Day"
archiveNumbering="Rolling"
maxArchiveFiles="7" />
Adjustments to primedocs.config:
<primedocs ... aspNetCoreDataProtectionDirectory="D:/Apps/primedocs/">
...
<apps>
<add ... name="DataSourceAdminApp" logFilePath="D:/Apps/primedocs/" type="DataSourceAdminApp" workingDirectoryPath="D:/Apps/primedocs/DataSourceAdminApp/" />
</apps>
</primedocs>
InstallLegacy.ps1
In earlier versions of primedocs, Install.ps1 was used for both installing and updating primedocs. As of version 4.0.30057.0, these two use cases have been separated. The previous Install.ps1 is still available as InstallLegacy.ps1.
Adjustments can be made in the InstallLegacy_Customization.ps1 file if it is not a standard installation. The corresponding setting options are described in the file.
Execution Policy
The PowerShell execution policy must allow running the installation scripts (.ps1 files). The scripts are signed; with the Windows Server default setting (RemoteSigned), no adjustment is usually necessary.
If a more restrictive policy prevents execution, adjust the execution policy temporarily for the current PowerShell process only (recommended approach — the setting only applies until the PowerShell session is closed):
Set-ExecutionPolicy Unrestricted -Scope Process
The following question must be answered with y for "Yes":
Execution Policy Change
The execution policy helps protect you from scripts that you do not trust. Changing the execution policy might expose
you to the security risks described in the about_Execution_Policies help topic at
http://go.microsoft.com/fwlink/?LinkID=135170. Do you want to change the execution policy?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "N"): y
A permanent, machine-wide change (Set-ExecutionPolicy Unrestricted without -Scope) is not recommended.