Azure Data Box: Fix Setup, Transfer & Config Errors
Why This Is Happening
You've ordered an Azure Data Box because you need to move a massive amount of data , we're talking dozens or hundreds of terabytes, into Azure without destroying your WAN link for weeks on end. Smart move. But somewhere between "device arrived at my data center" and "data is in Azure Storage," things went sideways. The local web UI won't load. Copy jobs are stalling. The device isn't being recognized after you shipped it back. The Azure portal shows an error you've never seen before.
I've seen this exact situation play out on dozens of enterprise migrations. The frustrating thing about Azure Data Box errors is that they sit at the intersection of physical hardware, networking, Azure portal permissions, and storage account configuration. When something breaks, the error message rarely tells you which layer is actually the problem. You get a generic "device connection failed" and a link to documentation that assumes everything is working correctly.
Here's the reality of what actually goes wrong most often:
Network misconfiguration on first setup. The Data Box local web UI runs on a fixed IP you configure during initial setup. If your data center network team isn't looped in, or if the management port and data ports get mixed up, you'll spend hours wondering why you can't reach the UI at all. The device ships with a default static IP of 192.168.100.10 for the MGMT port, and a lot of people try to connect to that without first configuring it for their actual subnet.
Certificate and browser trust issues. The local web UI uses a self-signed certificate by default. Chrome, Edge, and Firefox all handle this differently in 2026. Some corporate endpoint security tools will actively block connections to self-signed certs on internal IPs, so you sit there clicking "Connect" and nothing happens, with no obvious error.
Storage account permissions not set correctly before the device ships back. Your data won't upload automatically if the service principal tied to your Data Box order doesn't have the right role assignments on your target storage account. This is a silent failure, the device gets wiped at the Azure datacenter and you never get your data.
Copy job failures mid-transfer. SMB and NFS copy jobs can stall or fail silently when there are file path length violations, unsupported characters in file names, or metadata that Azure Blob or Azure Files doesn't accept. The error log exists, but most people don't know where to find it.
Whether you're doing a one-time migration of an on-premises VM farm, seeding a backup repository with a partner like Commvault or Veeam, or running periodic uploads from an energy exploration site, the fixes below cover the full range of what you'll actually hit. Browse all Microsoft fix guides →
The Quick Fix, Try This First
Before you go deep on advanced troubleshooting, run through this checklist. In my experience, about 60% of Azure Data Box issues during initial setup are solved by one of these three things:
Step 1, Verify you're on the right port. The Data Box has multiple network ports. The MGMT (management) port is for accessing the local web UI only. Your actual data copy traffic should flow through the 10G-BaseT RJ45 ports (labeled DATA1/DATA2) or the 100-GbE QSFP28 ports for higher throughput. If you plugged your copy server into the MGMT port and can't get good copy speeds, that's the entire problem right there.
Step 2, Hard-reset the network configuration through the E-ink display. Every Azure Data Box has a small E-ink display on the front panel. This display shows you the current IP address assigned to each port and lets you confirm the device is powered and healthy. If the display shows no IP or an unexpected address, the device may not have applied your initial network config. Power-cycle the device and go through the network setup in the local web UI again from scratch.
Step 3, Re-download the device credentials from the Azure portal. Go to your Data Box order in the Azure portal, navigate to General > Device credentials, and copy the device password fresh. Don't use a saved password from earlier in the day, the portal can regenerate credentials during certain operations, and your old one stops working. Paste the new password directly; don't type it manually.
If the local web UI loads after doing these three things, you're back on track. Proceed to the step-by-step section below for completing the full setup correctly so you don't hit this again mid-copy.
Once the Azure Data Box arrives at your facility, before you touch a single cable, go to your Data Box order in the Azure portal and write down the device serial number and the unlock password. These live under General > Device credentials. You'll need both.
Now connect a laptop directly to the MGMT port using an RJ45 cable. Set your laptop's IP to a static address in the 192.168.100.x subnet, something like 192.168.100.5 with a subnet mask of 255.255.255.0. Open a browser and go to:
https://192.168.100.10You'll get a certificate warning. Click through it (in Edge: Advanced > Continue to 192.168.100.10). The Data Box local web UI login page appears. Enter the unlock password you copied from the portal. Do not confuse this with a Microsoft account password, it's a device-specific key.
Once logged in, go to Configure network interfaces. Here you'll set static IPs for your DATA ports to match your data center network. Confirm with your network team that you're using the right subnet and gateway, the device does not do DHCP on DATA ports by default, and it won't tell you if the gateway is wrong.
After saving, ping the DATA port IP from your copy server to confirm connectivity. If you get a reply, the device is correctly on your network. If not, double-check VLAN tagging, Data Box doesn't support 802.1Q VLAN tagging on the data interfaces, so the switch port must be an access port, not a trunk.
Here's where a lot of Azure Data Box migrations go wrong and nobody realizes it until the device is already back at the Azure datacenter. You need to configure your storage account association before you start copying data, not after.
In the local web UI, go to Connect and copy > Shares. The shares listed here correspond directly to containers in your Azure Storage account. The naming convention matters: the share name maps to the container name in blob storage, or the file share name in Azure Files. If your container doesn't exist yet in Azure, it gets created automatically during upload, but only if the service principal has Storage Blob Data Contributor or Storage File Data Privileged Contributor on the target storage account.
Go check this now, before you copy anything. In the Azure portal, open your storage account, go to Access Control (IAM), and verify that the managed identity tied to your Data Box order has the right role assignment. The order's managed identity is listed in the Data Box resource under Identity. Missing this step means your data silently fails to upload after the device is shipped back, and the disks get wiped before you find out.
For SMB shares, get the share credentials from the local web UI under Connect and copy > SMB. Map the drive from your copy server using those exact credentials. For NFS, the UI gives you the mount command to run directly on a Linux copy host. Either way, do a test write of a small file before starting your full copy job, confirm the file appears in the share and you can read it back.
This step saves enormous pain. Azure Data Box includes a built-in data validation tool. Before you start your main copy job, especially if you're migrating legacy file servers, run validation against a sample of your data set first.
In the local web UI, go to Connect and copy > Error logs. After any copy operation, this section shows you exactly which files failed and why. Common failures include:
Error: File path exceeds 1024 characters
Error: Unsupported character in file name, \ : * ? " < > |
Error: File size exceeds per-blob limit (4.75 TB for block blobs)
Error: Metadata key contains invalid charactersAzure Blob Storage and Azure Files have strict naming requirements that your on-premises file server never enforced. A folder named Q3 Report & Summary (FINAL) is perfectly valid on NTFS. Azure doesn't like the ampersand. Files named CON.txt or PRN.log (Windows reserved device names) will fail silently.
The fix is to clean your source data before copying, not after. Use a PowerShell script to scan for invalid characters and path lengths before you start:
Get-ChildItem -Path "D:\DataToMigrate" -Recurse |
Where-Object { $_.FullName.Length -gt 256 -or
$_.Name -match '[\\:*?"<>|]' } |
Select-Object FullName | Export-Csv ".\invalid_paths.csv"Review invalid_paths.csv, rename or restructure the offending items, then start your copy. This one step prevents the most common "partial upload" complaints I hear from teams after their Data Box order closes.
Azure Data Box Next-Gen supports up to 100Gbps network interfaces. That's the ceiling, but most teams never get close to it because they're running a single robocopy job from one server. Here's how to actually push throughput.
First, use multiple copy sessions in parallel. The device's internal RAID 5 configuration across its storage array performs best with concurrent write streams. Run four to eight simultaneous robocopy jobs against different share folders:
robocopy "\\SourceServer\Share\FolderA" "\\DataBoxIP\ContainerA\FolderA" /E /Z /NP /R:3 /W:10 /MT:32 /LOG+:copy_log_A.txt
robocopy "\\SourceServer\Share\FolderB" "\\DataBoxIP\ContainerA\FolderB" /E /Z /NP /R:3 /W:10 /MT:32 /LOG+:copy_log_B.txtThe /MT:32 flag enables 32 threads per job. Adjust based on your copy server's CPU and RAM. More than 64 total threads across all jobs rarely helps and can cause SMB contention.
Second, check your NIC settings. If you're using the 100-GbE QSFP28 ports, confirm jumbo frames are enabled end-to-end, MTU 9000 on both the copy server NIC and the switch port. A mismatched MTU will cap your throughput at a fraction of what the hardware can do and you'll never get a clear error about it.
Monitor progress in the local web UI under Dashboard. You'll see the volume of data copied versus total capacity in real time. The SKU 1 device holds 120 TB usable; SKU 2 holds 525 TB usable. Plan your copy schedule so you finish with a day to spare before the return shipping deadline, rushing the final copy phase and shipping a partly-full device is a waste of the order cycle.
When your copy is complete, do not just box up the device and schedule a pickup. There's a specific shutdown sequence in the local web UI that prepares the device for transit, and skipping it can cause upload failures at the Azure datacenter.
In the local web UI, go to Prepare to ship. Click Start preparation. The device will perform a final integrity check, generate shipping labels, and lock the data volumes. This process can take 30 minutes to several hours depending on how much data is on the device. Do not power off the device while this runs.
Once preparation completes, the E-ink display on the front panel updates to show the return shipping label. The local web UI also provides a printable label under Prepare to ship > Shipping label. Download and print this, do not rely solely on the E-ink display, as it can be hard to scan in low-light loading docks.
After Microsoft receives the device, track the upload status in the Azure portal under your Data Box order. Go to Order > Overview, the status progresses through Received, Data copy in progress, and Copy completed. Once you see Copy completed, verify your data in the target storage account before the order reaches Order completed status. After that, per NIST 800-88r1 standards, the disks are wiped and you cannot recover anything. Set a calendar reminder to verify within 48 hours of receiving the "Copy completed" notification email.
Advanced Troubleshooting
Device shows as "Offline" in the Azure portal after shipping. This is normal, the device goes offline the moment it's powered down for transit. What's not normal is if it stays offline for more than five business days after you shipped it. Check the tracking number on the return label and confirm the carrier actually picked it up. If the carrier confirms delivery to the Azure datacenter and the portal still shows Offline after two business days, open a support ticket immediately. Don't wait, the data erasure schedule runs on a fixed timeline.
Upload completed but data is missing or corrupt. Go to your Data Box order in the Azure portal and download the copy log under Order > Data copy details > Copy log. This XML log lists every file that failed to upload and why. Compare it against your error log from the local web UI. If both logs show success but data is missing in the storage account, check that you're looking in the right container, the container name matches the share name on the device, which might not match what you expected.
Azure File Sync integration failing after Data Box import. If you're seeding an Azure file share via Data Box and then enabling Azure File Sync on top of it, the sync agent may report namespace conflicts or orphaned metadata. This happens when the file share content on the device wasn't formatted to match the Azure Files namespace exactly. After your Data Box upload completes, let the Azure File Sync cloud endpoint detect the new content before you add server endpoints. Give it 24 hours after the Data Box order reaches "Completed" before adding the first server endpoint.
SharePoint Online migration via SPMT stalling after Data Box upload. The SharePoint Migration Tool reads from Azure Blob Storage after a Data Box import. If SPMT throws throttling errors, it's usually because the blob storage account is on a standard tier and you're hitting IOPS limits. Move the migration blobs to a Premium block blob account, or rate-limit your SPMT job with the -SPOThrottle parameter.
Veeam or Commvault seeding job shows partial restore points. When using Data Box to seed a backup repository, a common pattern with both Veeam and Commvault, the backup application must re-catalog the imported data before restore points become available. In Veeam, run a Rescan on the repository after the Data Box import. In Commvault, trigger a Data Aging and Space Reclaim operation, then run a synthetic full backup to validate chain integrity.
If your Data Box order has been at the Azure datacenter for more than five business days and the portal still shows "Data copy in progress" with no movement, escalate immediately, don't wait. Similarly, if the copy log shows widespread failures with error code 0x80C86049 (storage service unavailable) or 0x80070005 (access denied) across more than 5% of your files, something is wrong at the service layer that self-service troubleshooting won't fix. Open a ticket at Microsoft Support and reference your Data Box order ID. Have your copy log and error log ready to attach, it cuts resolution time significantly.
Prevention & Best Practices
The teams I've seen get through Azure Data Box orders without incident all do a few things before the device even ships from Microsoft. None of this is complicated, it's just discipline around pre-work.
Pre-stage your storage account configuration. Before you order the device, create the target containers or file shares in your Azure Storage account. Assign the correct IAM roles to the Data Box managed identity as soon as the order is placed. Don't wait until the device arrives to figure out permissions, that's a two-day delay when the device is sitting on a pallet in your loading dock.
Audit your source data before the device arrives. Run the PowerShell path-length and invalid-character scan from Step 3 above on your entire data set. Rename or restructure anything that fails. If you're migrating from a legacy NAS with deep folder hierarchies or UNIX-style file names with colons and slashes, budget extra time, I've seen teams spend three days just cleaning file names on a 50 TB migration.
Plan your network topology in advance. Confirm with your network team that the switch ports you'll use are access ports, not trunks. Confirm MTU settings if you're using the 100-GbE interfaces. Pre-configure the static IPs so the first time you plug in the device you already know exactly what addresses to enter.
Set up monitoring on the target storage account during the upload window. After you ship the device back, enable Storage Account diagnostics and set an alert for zero write operations. If the upload is in progress and write ops suddenly drop to zero for more than an hour, something is wrong and you want to know immediately, not when you check the portal three days later.
- Download the copy log and error log from the local web UI before shipping the device, you lose direct access once it leaves your building.
- Use the Azure Data Box heavy (525 TB usable) if your data set is over 80 TB, you'll fill the standard 120 TB device and need a second order anyway, which doubles your timeline.
- For periodic large uploads (energy exploration, media production, scientific data), pre-negotiate a standing Data Box arrangement with your Microsoft account team, you can have a second device staged and ready before the first order closes.
- Always verify data in the target storage account and acknowledge completion in the Azure portal before the order auto-closes, once closed, the disks are wiped and there's no recovery path.
Frequently Asked Questions
What is Azure Data Box Next-Gen and how is it different from the regular Data Box?
Azure Data Box Next-Gen is the latest generation of the physical Data Box appliance. The most significant upgrade is the network interface speed, Next-Gen supports up to 100 Gbps network interfaces, which dramatically cuts the time it takes to fill the device compared to older generations. The device still ships in two storage capacity options (120 TB usable and 525 TB usable), still uses the same local web UI for setup, and still integrates with the same Azure portal ordering workflow. If you ordered a Data Box recently, you almost certainly received a Next-Gen unit, Microsoft has been shipping these as the standard device. The operational steps for setup, data copy, and return shipping are the same as the previous generation.
What is Azure Data Box Disk and when should I use it instead of the regular Data Box?
Azure Data Box Disk is a lighter-weight option in the same product family, Microsoft ships you a set of SSDs (up to 8 TB per disk, and you can order multiple disks) instead of the large appliance. It's the right choice when your data set is smaller, typically in the 8–40 TB range, and when you want something that's easier to handle physically and doesn't require a data center environment for setup. The Disk product doesn't have a local web UI, you connect it directly to a Windows machine via USB 3.0 and use the Data Box Disk tool to unlock and copy data. For anything above 40 TB, or if you need the higher network throughput of the 100-GbE interfaces, the standard Data Box or Data Box Heavy is the better fit.
What is Azure Data Box Heavy and what's the maximum capacity?
Azure Data Box Heavy is the largest device in the family, designed for data sets in the hundreds of terabytes range. It offers 525 TB of usable storage (600 TB raw), compared to 120 TB usable on the standard Data Box. The Heavy is a much larger physical unit, it weighs significantly more than the standard device (which itself is under 46 lbs) and requires forklift or pallet jack access in your data center. It supports the same 100-GbE QSFP28 interfaces as the Next-Gen Data Box, so you can fill it quickly if your infrastructure supports it. The Heavy is typically used for large-scale datacenter-to-Azure migrations, initial seeding of archive storage, or situations where you need to move a petabyte-class data set in a small number of shipment cycles.
My Azure Data Box local web UI won't load, I just get a connection timeout. What should I try?
Nine times out of ten this is either a wrong IP address, a network configuration issue, or a browser security block. First, check the E-ink display on the front of the device, it shows the current IP assigned to the MGMT port. Make sure your laptop is on the same subnet and you're browsing to that exact IP over HTTPS (not HTTP). If the display shows no IP at all, the device may not have an address assigned yet, connect directly with a crossover cable or a switch with no VLAN config and try the default management IP 192.168.100.10 after setting your laptop to a static address in that range. If you're on a corporate machine, try a different browser or a machine without endpoint security software, since certificate blocking is a common silent failure mode that mimics a network timeout.
How do I know if my data actually uploaded successfully after I shipped the device back?
Track the order status in the Azure portal under your Data Box order resource. The status will move through "Received at Azure datacenter," "Data copy in progress," and then "Copy completed." Once you see "Copy completed," go directly to your target Azure Storage account and spot-check your data, browse containers, check file counts, and if possible run a sample restore or validation job. Download the copy log from the portal under Order > Data copy details and look for any failed files listed in the error section. Do all of this before the order status reaches "Order completed," because that's when the NIST 800-88r1 disk wipe runs and the data on the device is gone permanently. Microsoft sends an email notification when copy completes, make sure someone is watching for it.
Can I use Azure Data Box for disaster recovery and exporting data out of Azure?
Yes, this is one of the most important export use cases the product supports. In a disaster recovery scenario, you place a Data Box export order through the Azure portal, and Microsoft copies your Azure data onto the device and ships it to you. Once it arrives, you restore the data to your on-premises environment directly from the device, no WAN dependency at all during the restore phase. This is especially useful when you're recovering a large volume of data quickly, since your network bandwidth would become the bottleneck in a traditional cloud-to-on-premises restore. Export orders follow the same portal workflow as import orders; the key difference is you specify a source Azure Storage account (or specific containers/blobs) rather than a destination. Government and compliance-driven exports, for example, moving data out of Azure US Secret or Top Secret clouds, follow the same mechanism.