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 such as are available from integrated on-premises/cloud monitoring applications such as WhatsUp Gold.

Round Trip Migration is not Available

Round trip migration (filesystem to Azure Blob and then back to filesystem) is not currently supported.