Overview

An RMS account can use more than one Azure storage account. One is marked Primary, and RMS stores every new asset there unless you name a different storage account. You can name a storage account in two places:

• When you create an asset, for example before you upload a source file.
• For the output of a job, by creating the job's output asset in that storage account.

This lets you keep content for different customers, departments or retention policies in separate storage accounts, each with its own access control, region, redundancy and billing.

Before you begin

You need:

• An RMS deployment and access to the RMS Console at apps.ravnur.com.
• Permission to create a storage account and assign roles in the Azure subscription that will hold it.
• For API use: an access token for the RMS API, and the subscription ID, resource group name and RMS account name used in RMS API paths.

Create the new storage account in the same Azure region as the RMS managed resource group. This avoids cross-region data transfer charges when RMS reads and writes media.

Step 1: Add a second storage account to RMS

Full instructions with screenshots are in Configure an external storage account for RMS. In short:

1. Create the storage account. In the Azure portal, create a storage account in your own resource group, not the RMS managed resource group, and in the same region.
2. Find the RMS managed identity. In the RMS managed resource group, find the managed identity named id-rms-<unique-suffix>.
3. Grant access. On the new storage account, open Access Control (IAM) and assign the Storage Blob Data Contributor role to that user-assigned managed identity.
4. Add it in the RMS Console. Go to Settings > Storage Accounts, add a new storage account record, enter the exact storage account name, and click Add new storage account.
5. Configure CORS. On the storage account, open Settings > Resource sharing (CORS) and add a rule: allowed origin https://apps.ravnur.com, methods GET, POST, PUT, HEAD and OPTIONS (or all), allowed and exposed headers *, max age 3600 seconds. Without this rule, Console uploads and job creation against this storage account fail.

Skip "Set Primary" if you want to keep your current default. A storage account you add without setting it as primary is a secondary account. RMS uses it only when a request or Console action names it. Click Set Primary only when you want new assets to go to this account by default; the change can take up to 10 minutes to propagate.

If you have more than one RMS account, do not set the default storage account created during deployment as primary for the other RMS accounts. Give each additional RMS account its own external storage account.

Step 2: Choose a storage account in the RMS Console

The Console lets you pick the storage account at two points:

• Uploading a file. When you upload media, select the storage account from the storage account list. The new asset and the uploaded file are stored there.
• Creating a job. When you create a job, select the storage account for the job output. RMS creates the output asset in that account, so the encoded renditions are written there.

If you leave the selection at its default, RMS uses the primary storage account. The input and output of a job can be in different storage accounts.

Step 3: Choose a storage account through the RMS API

In the RMS API, the storage account belongs to the asset, not the job. You set it with the properties.storageAccountName field when you create an asset. To send a job's output to a specific storage account, create the output asset in that account first, then name that asset in the job's outputs. Jobs have no storage account field of their own.

The examples below use these placeholders:

Let {base} stand for https://{rms-domain}/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Media/mediaServices/{accountName}.

Check which storage accounts are attached

Get the RMS account and read properties.storageAccounts. Each entry has an id and a type of Primary or Secondary.

GET {base}?api-version={api-version}
Authorization: Bearer {token}

Create an asset in a specific storage account

Use this for source files you upload yourself.

PUT {base}/assets/input-asset-001?api-version={api-version}
Authorization: Bearer {token}
Content-Type: application/json

{
  "properties": {
    "description": "Source file for job 001",
    "storageAccountName": "storage2"
  }
}

The response returns the asset with its container and storageAccountName. Call listContainerSas on the asset to get an upload URL for that container, then upload the file as usual.

Omit storageAccountName and RMS creates the asset in the primary storage account.

Send job output to a specific storage account

1. Create the output asset in the target storage account:

PUT {base}/assets/output-asset-001?api-version={api-version}
Authorization: Bearer {token}
Content-Type: application/json

{
  "properties": {
    "description": "Encoded output for job 001",
    "storageAccountName": "storage2"
  }
}

2. Submit the job and name that asset as the output:

PUT {base}/transforms/{transformName}/jobs/job-001?api-version={api-version}
Authorization: Bearer {token}
Content-Type: application/json

{
  "properties": {
    "input": {
      "@odata.type": "#Microsoft.Media.JobInputAsset",
      "assetName": "input-asset-001"
    },
    "outputs": [
      {
        "@odata.type": "#Microsoft.Media.JobOutputAsset",
        "assetName": "output-asset-001"
      }
    ]
  }
}

The input asset can be in any attached storage account. A transform with several outputs takes one output asset per output, and each can be in a different storage account.

The Azure Media Services v3 SDKs work the same way: set StorageAccountName on the Asset object before calling CreateOrUpdate.

How RMS chooses a storage account

Notes and troubleshooting

• Set the storage account when you create the asset. Choose it up front for each asset; plan where content belongs before you upload or encode.
• Use the exact name. storageAccountName is the storage account name only, such as storage2, not a full Azure resource ID or URL. It must match a storage account listed in Settings > Storage Accounts.
• Uploads or jobs fail in the Console for the new account. Check the CORS rule on that storage account, then clear the browser cache. CORS changes can take 1 to 5 minutes to apply.
• Access errors when RMS reads or writes the account. Confirm the RMS managed identity (id-rms-<unique-suffix>) has Storage Blob Data Contributor on the storage account.
• New assets still land in the old account after you change the primary. The primary change can take up to 10 minutes to propagate.

Related articles

• Configure an external storage account for RMS
• RMS Console: Media Asset upload
• How to get your RMS domain