Azure Parameter Description

Configuration example

Azure Versioning Blob Container

The Azure configuration described below (versioned blob container) supports object individual retention as well as legal hold functionality.

To use this feature, it is necessary to create a container with the "version-level immutability" option. See: Configure immutability policies for blob versions - Azure Storage

tia Content Server will manage the retention periods do not set default retention times on Azure.

This can be enabled in the Azure StorageAccount in a manually creation process of a container or via a corresponding configuration in tia Core, which is described below.

If the container creation is to be done by tia core, the following parameters must be added to the repository.cfg.

Parameter Name	DataType	Optional	Default	Description	Example/Values	Available since Version

Parameter Name	DataType	Optional	Default	Description	Example/Values	Available since Version
allowcreatecontainer	Boolean	yes	false	If the container does not exist, it will be created by the application.	true/false	2.0.8
enableversioning	Boolean	yes	true	If the application (tia® Core) is authorized to create containers and this parameter is additional enabled, the property "Enable ImmutableVersioning" is set. The following customizing is mandatory for this: Reference: Azure | [inlineExtension]Versioning for Azure Storage	true/false	2.0.8
management.clientId	String	yes		Azure credentials to automatically create containers with the "Enable ImmutableVersioning" setting enabled: Reference: https://github.com/IBM/IBMDeveloper-recipes/blob/main/how-to-procure-tenant-id-client-id-and-client-secret-key-to-connect-to-microsoft-azure-data-lake-storage-gen2/index.md Open		2.0.8
management.clientSecret	String	yes				2.0.8
management.tentantId	String	yes				2.0.8
management.subcriptionId	String	yes				2.0.8
management.resourceGroupName	String	yes				2.0.8
management.accountName	String	yes				2.0.8

Configuration example immutability policies

Container naming convention:

Container naming

A container name must be a valid DNS name and comply with the following naming rules:

• Container names must begin or end with a letter or number and may contain only letters, numbers, and hyphens (-).

• Each hyphen (-) must be immediately preceded and followed by a letter or number; in addition, multiple hyphens may not directly follow each other.

• The container name must contain lowercase letters only.

• Container names must be between 3 and 63 characters long.

Reference: Naming and Referencing Containers, Blobs, and Metadata - Azure Storage

0er Container (Feature for Migration) (not supported by azureblobstorev2)

As of tia® Core version 2.0.5, it is possible to configure a container for storing "expired" documents.

If a document with expired “expirationDate” is archived (during migration process) or updated, this document will be moved into the configured container “0” (with corresponding information on the "original" document).

Managed Identity

Managed Identity bewares you of copying and configuring security relevant parameters. It only works if blob store and tia core is hosted in Azure. (Same is valid for SQL db)

Azure knows 2 kinds of managed identity. Tia core can use both. Here shown is only server managed identity. On tia core configuration this distinction has no influence.

Managed Identity (Storage Account)

The blob store needs to have the role “Storage Blob Data Contributor”. There you add the app id of tia core. Then you can configure for blob store the storageendpoint instead of connectionstring.

Here the way to allow tia core to use managed identity.

• enter resource group

  Open

  

• select your resource group or create a new one

• select your storage account:

  Open

  

• enter access control (IAM):

   

• Add a roll “Storage Blob Data Contributor”

• use search bar and enter enter: storage Blob Data Contributor

  • press next

• press select members

• paste the tia core app id in search bar

  • press select

  • press review and assign