Service Integration - Remote File Store: Azure Blob Service (Best Practices)

Before you deploy your MOVEit Transfer file store to Azure Blobs, consider the guidelines and best practices in the table that follows.

Important: Your application server (MOVEit Transfer Server) and database need to be configured for the same time zone. You can reveal the configured time zone to users using Org-level controls (SETTINGS -> Display -> Regulatory Compliance -> "GMT" timezone offset statement).

It is best practice to leverage Azure Blob storage if you are running a MOVEit Transfer instance from Azure and if you are running the Azure Storage Service in the same Azure region (for lowest latency).

Best Practice/Guideline	Description
Only MOVEit Transfer Files and Packages are served from Azure Blob Storage	While not a guideline, this is a difference between MOVEit Transfer file stores that use Azure Blob storage in contrast with network attached storage or other variants of shared/mounted file systems. When you use Azure Blob storage for your MOVEit Transfer file store, non-root file store files such as logs, certs, Web UI branding, and licenses remain "local" (or, in the case where MOVEit Transfer was deployed as a Web Farm, they remain on the mounted file system that provides the UNC identified file share). Non-root file store files are not stored/served from Azure Blobs. For more information on converting your current file store to an Azure Blob file store, see the Release Notes.
Secure and rotate your API keys	MOVEit Transfer uses the Azure API key along with a storage service name to build its connection string to its file store in Azure Blob storage. Consider these best practices with respect to this key: Ensure the confidentiality of this critical connection string attribute. Safeguard the key. Do not share it. Rotate it routinely and regularly. You can rotate your primary API key by applying the secondary key in the MOVEit Transfer Config to promote confidentiality while maintaining availability of the file store. For web farm deployments and for maintaining production availability operations maintenance, keep track of which MOVEit Transfer instances use a given key. Unless down for maintenance, they should all have a current generation of either a primary or secondary key. Important: To ensure availability of the blob file store to MOVEit Transfer, take care to maintain a valid API key (either primary or secondary) as part of your connection information in the MOVEit Transfer Config. Warning: If you regenerate a primary or secondary API key at the Azure Portal or equivalent, the regenerated key revokes the key it replaces (which could be still part of the configuration at the MOVEit Transfer Server). Regenerating a key within Azure without rolling to a secondary key within MOVEit Transfer config will interrupt availability to the file store.
Do not use Azure Snapshots	Azure Snapshots are neither expected nor supported by the MOVEit Transfer filesystem. Restoring from a snapshot can preempt the data model maintained and audited by MOVEit Transfer. Azure Snapshots will effectively corrupt your file store. Warning: Azure Snapshots interfere with MOVEit Transfer Server operations and are not supported.
Use AzCopy or similar for Backup/Restore	After migrating your file store to Azure Blobs, the MOVEit Transfer Backup/Restore utility still works on your core configuration files, certs, and settings but it does not backup the blob file stores (in other words your MOVEit Transfer files and packages). You can use AzCopy to backup/sync/restore your file store. With AzCopy you can backup blob storage to a local store, blob storage to another blob storage service, and so on.
Increase the default file size	Max Blob size can be adjusted if your MOVEit Transfer deployment has very large files. The default Blob (file) size of Azure Blobs is smaller than a default maximum file allowed on a Windows Server File System.
Hot storage tier is recommended	The Azure Storage Hot tier provides upload and download performance you expect for your users. Ensure your MOVEit Transfer VM and blob storage service use the same Azure region (for lowest latency).
SysCheck does not report usage	When blob storage is used, MOVEit Transfer SysCheck does not return disk usage statistics for your file store. Azure Blob storage is elastic and can be monitored by way of billing, SLA, and other reports available from integrated on-premises/cloud monitoring applications such as WhatsUp Gold.
Key Encryption Rotation will Not Rotate Azure Storage Keys	MOVEit Transfer Key Encryption Rotation available for deploying fresh at-rest encryption keys is not supported for Azure Blob storage.
Round Trip Migration is not Available	Round trip migration (filesystem to Azure Blob and then back to filesystem) is not currently supported.

Note: For information and guidelines regarding security and key management of Azure Blob storage, see the Microsoft Azure Documentation.

Azure Blob Service Differences from a Network Mounted or Local Windows File Store

Azure Blob storage is designed for scale and cost benefit. In addition to these benefits, there are some features necessary to a local Windows File Store (or network-mounted equivalent) that do not apply to Azure Blob storage.

There is no folder level consistency check. In Azure, there is no concept for folders.
MOVEit Transfer System check report disk usage metrics do not apply to Azure Storage.
Max file size and default max size differ between Azure Storage Service and NTFS (Windows), but you can adjust the current file size limit.

Important: Audit logs and Org Info are unaffected by moving your file store to Azure Blob Storage.