> For the complete documentation index, see [llms.txt](https://docs.inforiver.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.inforiver.com/inforiver-enterprise-on-prem/upgrade/update-inforiver-setup-using-delta-template.md).

# Update Inforiver Setup Using Delta Template

### Microsoft Azure

The following pages will guide you through the update process of **Inforiver Add-on** in your Azure subscription. The deployment process is straightforward as long as the instance details are valid and all requirements are met before you begin.

### Checklist

Before proceeding further, please verify whether you have the following details.

* Azure subscription of the Inforiver deployment
* Azure Resource Group of the Inforiver deployment
* Inforiver Designated Administrator User Principal Name
* All the domain names, that you want to allow users to log in automatically for comments
* Azure AD Tenant ID
* Azure AD app Client ID
* Azure AD app Client Secret
* SMTP Host Address
* SMTP Port Number
* SMTP Username
* SMTP Password
* SMTP From Email Address
* Inforiver License Key
* Inforiver Docker Password
* Image Version - the target Inforiver build to upgrade to (for example, OPV4.6.9.0)
* Container Secret used by your existing deployment
* Existing Virtual Network and subnet names of your current deployment
* Existing SQL Server admin username and password
* Existing Redis resource name and type (Managed Redis or Cache for Redis)
* Existing Inforiver and InfoBridge container IPs (required only for App Service-only upgrades)
* The deploying user must have the **Contributor** and **User Access Administrator** roles in the deploying resource group. If the Inforiver VNet is located in a different resource group, then the user must also have the **User Access Administrator** role in that resource group.

### Resource Creation

1. Log in to Azure using [https://portal.azure.com](https://portal.azure.com/).
2. Click **Create a resource** from the Azure Services section.
3. Search for **Inforiver Addon** from the **Azure Marketplace** and select the option.
4. Select **Inforiver Addon (Delta) – Only for upgrade** under the dropdown menu.
5. Click **Create**.

<figure><img src="/files/AvUdBTaxqay8hvo4kBcV" alt=""><figcaption></figcaption></figure>

### Basics

In this section, you'll configure the basic details for upgrading an Inforiver deployment. Under **Basics**, fill in all the project and instance details.

* Choose the **Subscription** that your existing deployment is part of.
* Choose the **Resource Group** that your existing deployment is in.
* Choose the same **Region** as your existing deployment instance.
* Provide the **Solution Name**. Use the same name as your existing deployment, with no space or special characters.
* Provide the **Container Registry Password** (Docker token) that you collected from the previous steps.
* Provide the **Container Secret** – the same shared secret used across the App Service and containers (a random string of at least 32 characters).
* Provide the **Image Version** tag for the upgrade (for example, OPV4.6.9.0).

<figure><img src="/files/WIsb3VEltjVeRNOnujSY" alt=""><figcaption></figcaption></figure>

### Network Configuration

In this section, you'll configure the network for the Inforiver deployment. For an upgrade, reuse the same **Virtual Network** and subnets that your existing deployment already uses.

* Under **Network Configuration**, select the existing **Virtual Network** that your current Inforiver deployment is part of. Select the respective subnets for app service and private resources (e.g., Redis, SQL Server, Key Vault, etc.).
* The third subnet **(ACI/AKS/ACA Subnet)** field always displays the subnet used by your current background processor.
  * For an **ACI update**, it displays the existing **ACI** subnet.
  * For an **ACI-to-AKS** migration, it displays the existing **ACI** subnet, while you specify a new subnet for the AKS deployment.
  * For an **AKS update**, it displays the existing **AKS** subnet.
  * For an **ACI-to-ACA** migration, it displays the existing **ACI** subnet, while you specify a new subnet for the ACA deployment.
  * For an **ACA update**, it displays the existing **ACA** subnet.

{% hint style="info" %}

#### How the third subnet works

The  third subnet **(ACI / AKS / ACA Subnet)** always refers to the subnet used by your current background processor.

* For an **ACI update** or an **ACI-to-AKS** migration, specify the existing **ACI** subnet. Even if you select **Deploy new AKS**, the new AKS subnet is configured separately by using the fields that follow.

* For an **AKS update**, specify the existing **AKS** subnet.

* For an **ACI-to-ACA** migration, specify the existing **ACI** subnet. The new ACA subnet is configured separately.

* For an **ACA update**, specify the existing **ACA** subnet.
  {% endhint %}

* Under **Custom DNS**, enable **Use custom DNS servers instead of Azure-provided DNS** only if you use custom DNS and provide the server IP addresses as a comma-separated list (for example, 10.0.0.4, 10.0.0.5).

* Under **NAT Gateway**, choose whether to **deploy a new NAT Gateway** or **use an existing one**. The NAT Gateway is associated with the **App Service**, **Container**, and **Private** subnets to provide a static outbound IP address.

  By default, the deployment names the NAT Gateway and its public IP as **`<solutionName>-natgw`** and **`<solutionName>-natgw-pip`**, respectively. If the existing NAT Gateway or public IP was provisioned manually with different names, enter those names in the **NAT Gateway Name** and **Public IP Name** fields during an update.

* Under **Background Processor**, choose how Inforiver runs its background jobs – **ACI (Default), AKS**, or **ACA**. The fields shown below this dropdown change with your choice.

<figure><img src="/files/7vzAOOmYkLTDseeeu77I" alt=""><figcaption></figcaption></figure>

#### Scenario 1: Update an ACI setup

1. Select **ACI (Default)** to update an existing ACI deployment.

   No additional deployment fields are displayed. The deployment uses the existing ACI subnet specified in the **ACI / AKS / ACA Subnet** field.
2. Select the **Product Type** that matches your existing deployment:
   * **Default** (deploy all components)
   * **Inforiver + InfoBridge**
   * **Inforiver**
   * **Editable**
3. Select an **Upgrade Mode**:
   * **Complete** - Deploy all components.
   * **App Service Only** - Update only the App Service and skip the containers.
   * **Containers Only** - Update the containers and App Service configuration.
4. If you select **App Service Only**, enter the existing **Inforiver Container IP** and **InfoBridge Container IP**.

<figure><img src="/files/E6q5KEOchFDOk360Eo5q" alt=""><figcaption></figcaption></figure>

#### Scenario 2: Migrate to AKS or update an existing AKS setup

<figure><img src="/files/NaGifc6aE5SYAlts4n8H" alt=""><figcaption></figcaption></figure>

1. Select **AKS** to migrate from **ACI** to **AKS** or to update an existing AKS deployment.

   Additional AKS configuration options are displayed.
2. Configure **Deploy new AKS**:

   * **Select** this to provision a new AKS cluster. Use this option when migrating from **ACI** to **AKS**. In that case, the third subnet **(ACI / AKS / ACA Subnet)** above continues to reference the existing **ACI** subnet (the migration source), while you configure a new AKS subnet by using the following settings:
     * **AKS Subnet Name** - Enter a name for the new AKS subnet.
     * **VNet Address Prefix** - Enter the expanded virtual network CIDR. The prefix must be **/23** or larger to accommodate the new AKS subnet.
     * **AKS Subnet Address Prefix** - Enter the CIDR for the AKS subnet. The prefix must be within the VNet address range. A **/24** subnet is recommended.

   <figure><img src="/files/SKcqENfy0PoaZQpWchol" alt=""><figcaption></figcaption></figure>

* **Leave it unselected** to update an existing AKS cluster in place, where the third subnet **(ACI / AKS / ACA Subnet)** field must reference the cluster's existing AKS subnet.

3. Configure the remaining AKS settings. These settings are available whether or not **Deploy new AKS** is selected.

* **AKS User Node VM Size** - Select the VM size for the user node pool, for example, **Standard\_D4s\_v5**.
* **AKS System Node VM Size** - Select the VM size for the system node pool, which is deployed with a single node.
* **Cluster Visibility** - Choose **Public** to expose the Kubernetes API server over the internet or **Private** to restrict access to the virtual network.
* **Kubernetes Service CIDR** and **DNS Service IP -** Specify the internal IP address range for Kubernetes services. Specify the IP address for the Kubernetes DNS service. The address must fall within the Kubernetes Service CIDR. These must not overlap with the VNet, AKS subnet, or on-prem networks.

{% hint style="warning" %}

### Important

You can configure **Cluster Visibility**, **Kubernetes Service CIDR**, and **DNS Service IP** only when you create the AKS cluster. These settings can't be changed during subsequent updates.
{% endhint %}

#### Scenario 3: Migrate to ACA or update an existing ACA setup

1. Select **ACA** to migrate from **ACI** to **ACA** or to update an existing ACA deployment.

   Additional ACA configuration options are displayed.
2. Configure **Deploy new ACA subnet**:
   * **Select** to create a new subnet for Azure Container Apps. Enter the following values:
     * **ACA Subnet Name** - Enter a name for the new ACA subnet.
     * **ACA Subnet Address Prefix** - Enter a subnet CIDR within the VNet address range. The subnet must use a **/27** address prefix to provide 32 IP addresses.
   * **Clear** to update an existing ACA deployment. The third subnet **(ACI / AKS / ACA Subnet)** field must reference the existing ACA subnet.

<figure><img src="/files/g02cVezoP1Cnn9amg7M2" alt=""><figcaption></figcaption></figure>

3. Select the **Product Type** that matches your existing deployment:

* **Default** (deploy all components)
* **Inforiver + InfoBridge**
* **Inforiver**
* **Editable**

4. Select an **Upgrade Mode**:

* **Complete** - Deploy all components.
* **App Service Only** - Update only the App Service and skip the containers.
* **Containers Only** - Update the containers and App Service configuration.

### Database Configuration

In this section, you will configure the Redis and SQL Server resources for the Inforiver deployment. You can also migrate from **Azure Cache for Redis** to **Azure Managed Redis**.

**Redis**

1. Under **Redis Enterprise**, select **Deploy a new Azure Managed Redis Enterprise** only if you are migrating from **Azure Cache for Redis** to **Azure Managed Redis**.
2. If you deploy a new Azure Managed Redis instance, select a **Redis SKU**:
   * **Balanced\_B1**
   * **Balanced\_B3**
3. If you use an existing Redis instance:
   * Select the **Existing Redis Type** (**Managed Redis** or **Cache for Redis**).
   * Enter the **Existing Redis Resource Name**.

**SQL Server**

1. Enter the **SQL Admin Username**.
2. Enter the **SQL Admin Password**. Use the password for the existing SQL database.

<figure><img src="/files/15QQ2odwsrKKnbWhzSSb" alt=""><figcaption></figcaption></figure>

### Workspace Configuration

In this section, you will configure the Inforiver workspace, Azure AD authentication, Key Vault, and monitoring resources.

#### Workspace details

1. Enter the **Workspace Administrator Email**, for example, `admin@contoso.com`.
2. Enter the **Workspace License Key** that you obtained earlier.
3. Enter the **Workspace Domain**. Separate multiple domains with commas (for example, `lumel.com,inforiver.com`).
4. Enter the **Admin Portal URL** in the format `https://<your-domain>/`.

#### Azure AD configuration

Enter the following details for the registered Azure AD application:

* **Azure AD Tenant ID**
* **Azure AD App Client ID**
* **Client Secret**

#### Key Vault

1. Choose whether to **deploy a new Key Vault** or **use an existing one**.
2. Enter the **Key Vault Name**. The name must be **3–24 characters** and globally unique.

When you use Azure Key Vault, deployment secrets, such as passwords and connection strings, are stored in the vault and referenced by the application. Otherwise, they are stored as environment variables.

{% hint style="info" %}
If you use an existing Key Vault whose name differs from the default `<solutionName>` naming convention, select the option to use an existing Key Vault and enter the existing resource name.
{% endhint %}

#### Monitoring

1. Choose whether to **deploy a new Log Analytics workspace** or **use an existing one**.
2. Enter the **Log Analytics Workspace Name**.

The Log Analytics workspace collects deployment and application diagnostic logs.

{% hint style="info" %}
If you use an existing Log Analytics workspace whose name differs from the default `<solutionName>` naming convention, select the option to use an existing workspace and enter the existing resource name.
{% endhint %}

<figure><img src="/files/G5DzEhgVW662msptoxSD" alt=""><figcaption></figcaption></figure>

<figure><img src="/files/4g3Awvc8lUFnN4BHzrPT" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
When **Key Vault** or **Log Analytics Workspace** is enabled, a text box appears showing a default name constructed from the solution name. If either resource already exists under a different name, you can manually enter that name in the text box instead.
{% endhint %}

### SMTP Configuration

In this section, you will configure the SMTP settings used for sending email notifications and comments.

1. Select the **SMTP Service Provider**: **Office365** and **Custom**.
2. Enter the **SMTP From Address**: This address is used as the sender for outgoing emails.
3. If you selected **Custom**, configure the following settings:
   * **SMTP Username** – Enter the username used to authenticate with the SMTP server.
   * **SMTP Password** – Enter the password for the SMTP account.
   * **SMTP Host** – Enter the SMTP server host name.
   * **SMTP Port** – Enter the SMTP server port.
   * **SMTP TLS Enabled** – Enable this option if the SMTP server supports TLS.
   * **SMTP Require TLS** – Enable this option if the SMTP server requires TLS for all connections.

{% hint style="info" %}
The **SMTP Username**, **SMTP Password**, **SMTP Host**, **SMTP Port**, **SMTP TLS Enabled**, and **SMTP Require TLS** settings are available only when **SMTP Service Provider** is set to **Custom**.
{% endhint %}

<figure><img src="/files/QK5suDuQ8eqzNyDMFJd7" alt=""><figcaption></figcaption></figure>

### Review + Create

In this final section, Azure validates your configuration before the upgrade is deployed.

1. Review all the details you entered across the **Basics**, **Network**, **Database**, **Workspace**, and **SMTP** sections.
2. Wait for the "Validation Passed” message to appear at the top of the page.
3. Click **Create** to start the upgrade deployment.
4. Once the deployment completes, verify that your Inforiver instance is running on the updated configuration.

Once the deployment is completed, you'll see the screen.as shown in the following image.

<figure><img src="/files/x1AykAME1TJG5zGo18Qo" alt=""><figcaption></figcaption></figure>

If you notice any errors, please contact the support team by emailing your error along with logs to <support@inforiver.com>.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.inforiver.com/inforiver-enterprise-on-prem/upgrade/update-inforiver-setup-using-delta-template.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
