Azure
- Stefan Franz
- Benjamin Schröder
- Fabian Nola
Azure Parameter Description
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. | 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.type = azureblobstorev2
<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 = 4194304Azure 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 |
|---|---|---|---|---|---|---|
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: Scalability and performance targets for standard storage accounts - Azure Storage
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).
<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
