1 Azure Parameter Description
- 1.1 Configuration example
2 Azure Versioning Blob Container
3 Managed Identity
- 3.1 Managed Identity (Storage Account)

Azure Parameter Description

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

Parameter Name	DataType	Optional	Default	Description	Example/Values	Available since Version
type	String	no		Definition of Content Service type.	azureblobstorev2
connectionstring	String	yes		Azure Connection String. Is obsolete if storageendpoint is set.	DefaultEndpointsProtocol=https;AccountName=<azurename>;AccountKey=<tiacore/UA==>;EndpointSuffix=core.windows.net	2.0.8
storageendpoint	String	yes		Used for Azure Managed Identity. Azure storage endpoint. If this is set the connectionstring is obsolete. Is uses with priority over connection string.	https://mystorageaccount.blob.core.windows.net/	3.8.0
container	String	no		Azure Container Name.	mycontainer	2.0.8
contrepinpath	Boolean	yes	true	Root folder starts with Repository Syntax.	true/false	2.0.8
cleanversions	Boolean	yes	true	true = deletes all previous versions for "UPDATE" and "DELETE" operations in buckets with versioning. false = all versions still persist.	true/false	1.9.0
calculatestreamhash	Boolean	yes	true	After successful encryption, the hash values are recalculated.	true/false	2.0.8
invalidcharacters	String	yes		This parameter can be used to define additional characters that require the name to be encoded for Azure.	<user>, z.B. \uFFFE\uFFF9\uFFF0	2.0.8
region	String	yes	azure	Selection of the region for the creation of a new container.	azure, germany, us, china	2.0.8
minparallelsize	Num	yes	4194304	Limit for upload in bytes for parallel upload with multiple threads.		2.0.8
maxconcurrency	Num	yes	2	Maximum amount of threads for parallel uploads.		2.0.8
blocksize	Num	yes	4194304	Blocksize in Bytes for parallel upload.		2.0.8
singleuploadsize	Num	yes	4194304	Chunk size for parallel upload in bytes.		2.0.8

Configuration example

<Repo>.contentservice.azureblobstorev2.type = 
<Repo>.contentservice.azureblobstorev2.storageendpoint =
<Repo>.contentservice.azureblobstorev2.connectionstring = 
<Repo>.contentservice.azureblobstorev2.container = 
<Repo>.contentservice.azureblobstorev2.contrepinpath = true 
<Repo>.contentservice.azureblobstorev2.cleanversions =  true
<Repo>.contentservice.azureblobstorev2.calculatestreamhash = true
<Repo>.contentservice.azureblobstorev2.invalidcharacters= 
<Repo>.contentservice.azureblobstorev2.region = azure
<Repo>.contentservice.azureblobstorev2.minparallelsize = 4194304
<Repo>.contentservice.azureblobstorev2.maxconcurrency = 2
<Repo>.contentservice.azureblobstorev2.blocksize = 4194304
<Repo>.contentservice.azureblobstorev2.singleuploadsize = 4194304

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: https://learn.microsoft.com/en-us/azure/storage/blobs/immutable-policy-configure-version-scope?tabs=azure-portal

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		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

<Repo>.contentservice.azureblobstorev2.allowcreatecontainer=false
<Repo>.contentservice.azureblobstorev2.enableversioning=true
<Repo>.contentservice.azureblobstorev2.management.tenantId=
<Repo>.contentservice.azureblobstorev2.management.clientSecret=
<Repo>.contentservice.azureblobstorev2.management.clientId=
<Repo>.contentservice.azureblobstorev2.management.subcriptionId=
<Repo>.contentservice.azureblobstorev2.management.resourceGroupName=
<Repo>.contentservice.azureblobstorev2.management.accountName=

Access is allowed by Access Keys or Shared Access Signature Keys. It is important that tia core can access Object and the container itself. More permissions are required when tia core should create containers.

To be aware of the limits e.g. for memory and data throughput per storage account, the following article is recommended: https://learn.microsoft.com/en-us/azure/storage/common/scalability-targets-standard-account?toc=%2Fazure%2Fstorage%2Fblobs%2Ftoc.json

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: https://learn.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-containers--blobs--and-metadata

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).

<Repo>.contentservice.azureblobstore.container=test1                    # Container for metadata and retention information
<Repo>.contentservice.azureblobstore.container.retention.0=test-0       # Container for expired documents

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
select your resource group or create a new one
select your storage account:
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