Fix Azure Data Manager for Agriculture Issues & Data Export
Why This Is Happening
If you're landing here because something broke inside Azure Data Manager for Agriculture , or worse, because you just learned the service is being retired and you're staring at a countdown clock, I completely understand the panic. I've walked multiple enterprise agri-tech teams through this exact situation, and the combination of a retiring preview service, opaque API errors, and the genuine threat of data loss is one of the more stressful spots an Azure architect can find themselves in.
Here's the hard truth first: Azure Data Manager for Agriculture (Preview) was officially retired on September 1, 2025. Microsoft announced this with roughly a five-month runway. If you're reading this after that date, the service no longer receives functional or security updates. Microsoft's retention policy means your data is deleted 30 days after the retirement date, so the data extraction steps in this guide are not optional; they're urgent.
That said, a large portion of the errors and setup headaches people ran into with Azure Data Manager for Agriculture happened well before retirement was ever announced. The service was always a preview, which means the rough edges were real. Teams hit problems installing the initial instance, struggled to get the hierarchy model configured correctly, ran into rate-limiting walls when ingesting satellite or sensor data at scale, and watched ISV solution integrations fail with cryptic HTTP 4xx responses that Microsoft's portal surface did nothing to explain.
The root causes cluster into four buckets. First, permission and role assignment gaps, the service requires specific Azure RBAC roles that aren't automatically provisioned, and missing a single assignment silently blocks entire data flows. Second, hierarchy model misconfigurations, Azure Data Manager for Agriculture organizes everything around a strict hierarchy of parties, farms, fields, seasons, and crop zones, and if that hierarchy isn't built in the right order, downstream data ingestion jobs fail with misleading error messages. Third, satellite and sensor ingestion pipeline failures, the imagery enhancements shipped in November 2023 changed reprojection methods and nomenclature, and any code written before that update will silently produce incorrect data unless updated. Fourth, throttling, the service enforces per-tenant request limits, and teams running high-frequency sensor polling or bulk ingestion jobs hit HTTP 429 errors without realizing it until dashboards went dark.
Microsoft's in-portal error messages for most of these are not helpful. You get a generic "operation failed" or a bare HTTP status code with no guidance on which permission is missing or which hierarchy node is malformed. That's what this guide is here to fix.
Whether you're racing to export your data before Microsoft's deletion window closes, or you're digging through archived logs trying to understand what went wrong with a now-retired deployment, the steps below give you the exact paths, commands, and API calls you need. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If you're in data-extraction mode right now, your primary goal is getting your farm data out of Azure Data Manager for Agriculture before Microsoft's deletion window closes, here's what to run immediately. This is the fastest path to a complete export using the service's REST API endpoints.
Open Azure Cloud Shell (or any terminal with the Azure CLI installed and authenticated) and run the following sequence. You'll need your instance's base URL, which follows the pattern https://<your-instance-name>.farmbeats.azure.net, and a valid bearer token from your Azure AD tenant.
# Step 1: Authenticate and grab a token
az login
az account set --subscription "<your-subscription-id>"
# Step 2: Get a bearer token for the FarmBeats resource
TOKEN=$(az account get-access-token \
--resource "https://farmbeats.azure.net" \
--query accessToken -o tsv)
# Step 3: Export all parties (top-level hierarchy nodes)
curl -X GET \
"https://<your-instance>.farmbeats.azure.net/parties?api-version=2023-11-01-preview" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-o parties_export.json
# Step 4: Export farms for a specific party
curl -X GET \
"https://<your-instance>.farmbeats.azure.net/parties/<partyId>/farms?api-version=2023-11-01-preview" \
-H "Authorization: Bearer $TOKEN" \
-o farms_export.jsonRepeat the farms call for every party you have. Then work down through fields, seasons, crop zones, and activity records. The search endpoints, especially the consolidated activity search endpoint shipped in October 2023, let you pull records by party ID in a single call rather than paginating through individual resource types. That's your fastest route to a complete export.
Once you have JSON dumps of every resource type, save them to Azure Blob Storage immediately. Don't rely on keeping them only on a local machine.
Before anything else works, data export, API calls, ISV integrations, your Azure account needs the right role assignments against the Azure Data Manager for Agriculture resource. This is the most common silent failure mode I've seen, and Microsoft's portal gives you absolutely no indication that a missing role is the actual problem.
Navigate to the Azure portal at portal.azure.com, find your Azure Data Manager for Agriculture instance under All Resources, then select Access control (IAM) from the left-hand menu. Click View my access.
For full read/write access to farm data, you need either the AgriService Contributor or AgriService Owner role at the resource scope. For read-only export operations, AgriService Reader is sufficient. If you see only generic Azure roles like Contributor or Reader without the AgriService prefix, your account cannot call the data plane APIs regardless of what subscription-level permissions you hold.
To add the correct role, click Add > Add role assignment, search for "AgriService", select the appropriate role, then assign it to your user account or service principal. Role propagation in Azure typically takes 2–5 minutes.
# Verify role assignments via CLI
az role assignment list \
--scope "/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.AgFoodPlatform/farmBeats/<instance-name>" \
--output tableAfter you add the role, try your API call again. If it still fails with HTTP 403, check whether your organization has Azure AD Conditional Access policies that might be blocking token issuance for the FarmBeats resource scope, that's a separate problem covered in the Advanced Troubleshooting section below.
Azure Data Manager for Agriculture uses a strict parent-child hierarchy to organize all farm data. The order is: Party → Farm → Field → Season → Crop Zone → Management Zone. Every data ingestion operation, satellite imagery, weather forecasts, sensor readings, farm activity records, must be tied to a node in this hierarchy. If you try to attach data to a node whose parent doesn't exist yet, you get a vague HTTP 404 or 400 with a body that says something like "resource not found" but doesn't tell you it's the parent that's missing.
The fix is always the same: build the hierarchy top-down. Never skip levels. Here's the correct creation sequence using the REST API:
# 1. Create a Party first
POST /parties
{
"id": "party-001",
"name": "Sunrise Farm Operations",
"description": "Primary grower account"
}
# 2. Create a Farm under that Party
POST /parties/party-001/farms
{
"id": "farm-001",
"name": "North Sector Farm"
}
# 3. Create a Field under the Farm
POST /parties/party-001/fields
{
"id": "field-001",
"farmId": "farm-001",
"name": "Plot A - Corn"
}A common mistake is trying to create fields directly without specifying the farmId property. The API will accept the request without error in some cases but will create an orphaned field that later ingestion jobs can't find. Always include the parent reference explicitly even when the endpoint doesn't require it.
If you've already created orphaned resources, list them with a GET call on the resource type, filter by missing parent IDs, and delete and recreate them in the correct order. The Microsoft documentation confirms that the hierarchy model is the underlying logic that drives all insight generation, so a malformed hierarchy means silent failures, not noisy ones.
Satellite ingestion was one of the most actively updated parts of Azure Data Manager for Agriculture. The November 2023 release brought four significant changes: search caching behavior, pixel source control via item IDs, a new reprojection method, and nomenclature updates. Any satellite ingestion pipeline built before November 2023 is almost certainly broken or producing incorrect results.
The most impactful breaking change is the reprojection method update. The old method introduced measurable distortion for farms outside equatorial regions, farms at higher latitudes in North America, Europe, and parts of Asia were getting pixel coordinates that didn't accurately reflect on-the-ground dimensions. The new method corrects this, but it means that bounding boxes you pass to the satellite ingestion API produce different tile sets than they did before. If your vegetation index maps look shifted or your field boundaries no longer align with imagery, this is why.
To fix this, you need to resend your satellite data ingestion jobs using the updated API version. Specify the item ID explicitly in your request to lock pixel source to a single tile, this is the new itemId parameter introduced in the November 2023 update:
POST /parties/{partyId}/satelliteDataIngestionJobs/{jobId}
{
"farmerId": "party-001",
"fieldId": "field-001",
"startDateTime": "2024-01-01T00:00:00Z",
"endDateTime": "2024-06-30T00:00:00Z",
"provider": "Microsoft",
"source": "Sentinel_2_L2A",
"data": {
"imageNames": ["NDVI", "EVI", "LAI"],
"imageFormats": ["TIF"],
"imageResolutions": [10, 20]
}
}After submitting, poll the job status endpoint. A successful satellite ingestion job transitions through Waiting → Running → Succeeded. If you see Failed, check the errorCode field in the response body, common values include AUTHORIZATION_FAILED (role issue from Step 1), FIELD_NOT_FOUND (hierarchy issue from Step 2), and PROVIDER_UNAVAILABLE (external satellite provider rate limit).
Sensor data in Azure Data Manager for Agriculture flows through a specific push model. Sensors must be registered in the system before they can push readings, and the registration process is different depending on whether you're a sensor partner (an ISV or device manufacturer registering sensor types) or a customer (registering individual sensor devices and consuming their data).
I've seen many teams skip the partner registration step entirely and then wonder why their sensor push calls return HTTP 400. The sensor ingestion architecture requires that a sensor data model exists before any individual sensor can be registered against it. Think of it like a schema registry, you define what a sensor produces before you register a device that produces it.
The fix is to follow the correct registration order. Navigate through the Azure Data Manager for Agriculture documentation path: Using sensors → Set up sensors as a partner → Set up sensors as a customer. The partner setup creates the sensor data model; the customer setup registers the physical device. Both steps must complete before push ingestion will work.
For actively pushing sensor data, use the dedicated push endpoint:
POST /sensor-partners/{sensorPartnerId}/sensors/{sensorId}/data-ingestion-jobs/{jobId}
# Or for real-time push:
POST /sensor-partners/{sensorPartnerId}/sensors/{sensorId}/telemetry
{
"dateTime": "2024-05-15T10:30:00Z",
"properties": {
"soilMoisture": 32.4,
"soilTemperature": 18.7,
"unit": "percent"
}
}If push calls succeed with HTTP 202 but no data appears in your downstream queries, check the sensor's integrationId binding. If it's missing or pointing to a deleted ISV integration, readings are accepted but silently dropped. Re-create the integration binding, then retry the push.
The ISV solution framework in Azure Data Manager for Agriculture was one of its most powerful features, enabling connections to partners like Bayer's crop water use maps and custom generative AI copilots for agriculture. It was also one of the most common sources of cryptic errors.
ISV solution integrations require a separate installation step beyond just having the Azure Data Manager for Agriculture instance. In the Azure portal, under your instance, go to ISV Solutions in the left nav and verify that each integration shows a status of Active. A status of Pending usually means the ISV hasn't completed their side of the onboarding. Error status means the OAuth credential exchange between your tenant and the ISV's service principal has failed.
For the generative AI capability (released November 2023 and extended with Copilot templates in March 2024), failures most often come from missing plugin configurations. The generative AI layer in Azure Data Manager for Agriculture uses a plugin architecture where specific agriculture API groups, tillage, planting, applications, harvesting, are mapped to callable plugins. If a plugin isn't mapped, the AI simply won't include that data type in its responses, with no error message.
# Check generative AI plugin registration via API
GET /copilot/plugins?api-version=2024-03-01-preview
# Expected response includes entries like:
{
"value": [
{ "pluginName": "FarmOperations", "status": "Active", "capabilities": ["tillage", "planting", "applications", "harvesting"] },
{ "pluginName": "SatelliteInsights", "status": "Active" }
]
}If you were using the Copilot templates for agriculture (March 2024 release) to integrate proprietary data like agronomy PDFs or market price feeds outside Azure Data Manager for Agriculture, those templates use an orchestration framework with embedded data structures. If the orchestration framework loses its connection to external data sources, the copilot still answers but silently ignores the proprietary context. The fix is to re-verify each plugin's connection credentials in the template configuration and re-run a test prompt to confirm the proprietary data is being retrieved.
Advanced Troubleshooting for Azure Data Manager for Agriculture
If the step-by-step fixes above haven't resolved your issue, or you're dealing with an enterprise deployment involving private networking, domain-joined security controls, or large-scale data pipelines, here's where to dig deeper.
Diagnosing Throttling Errors (HTTP 429)
Azure Data Manager for Agriculture enforces per-tenant throttling limits on API calls. When you hit these limits, you get HTTP 429 responses with a Retry-After header. The mistake most teams make is writing retry logic that immediately retries on 429, this makes the problem worse by maintaining the high request rate that caused throttling in the first place.
The correct pattern is exponential backoff with jitter. On receiving a 429, read the Retry-After value (in seconds), wait that long plus a random jitter of 0–30 seconds, then retry. For bulk ingestion jobs like satellite batch submissions or historical sensor data imports, spread your API calls over time by adding deliberate delays between requests rather than firing them all at once.
# Example: Throttle-aware ingestion loop (Python pseudocode)
import time, random
for job in ingestion_jobs:
response = submit_ingestion_job(job)
if response.status_code == 429:
retry_after = int(response.headers.get('Retry-After', 60))
sleep_time = retry_after + random.uniform(0, 30)
time.sleep(sleep_time)
response = submit_ingestion_job(job)
elif response.status_code == 202:
time.sleep(1) # Courteous pacing between successful requestsAudit Log Analysis
Azure Data Manager for Agriculture supports audit logging through Azure Monitor. If you're investigating a past failure or trying to understand what API calls were made against your instance, go to your resource in the Azure portal, select Monitoring → Diagnostic settings, and verify that audit logs are being sent to a Log Analytics workspace or Storage Account. If diagnostic settings were never configured, you have no historical log data, another reason to act fast before the retirement window closes.
Once you have a Log Analytics workspace connected, query for failures with:
AzureDiagnostics
| where ResourceType == "FARMBEATS"
| where ResultType == "Failed"
| project TimeGenerated, OperationName, ResultDescription, CallerIpAddress
| order by TimeGenerated desc
| take 100Private Link Configuration
For enterprises using Azure Private Link with Azure Data Manager for Agriculture (to keep traffic off the public internet), the most common configuration error is forgetting to update your private DNS zone. The service's private endpoint requires a DNS record in the privatelink.farmbeats.azure.net zone. If that DNS entry is missing or pointing to the wrong IP, all API calls time out silently, which looks exactly like a permissions issue until you test DNS resolution directly.
# Test DNS resolution for your private endpoint
nslookup <your-instance>.farmbeats.azure.net
# Should resolve to a 10.x.x.x or 172.x.x.x private IP, not a public Azure IPConditional Access Policy Blocks
In enterprise tenants with strict Azure AD Conditional Access, the https://farmbeats.azure.net resource scope may not be explicitly allowed in your CA policies. This produces an authentication failure that looks like a 401 but is actually an access token issuance block. Check with your identity team to ensure the FarmBeats resource application ID is included in your allowed app registrations.
Prevention & Best Practices for Azure Data Manager for Agriculture
If you're in the middle of extracting data and planning your transition away from Azure Data Manager for Agriculture, building the right habits now will protect you in whatever platform you migrate to. These are the lessons I'd tell every team to internalize before they repeat the same mistakes on a new service.
Document your hierarchy model before you need it. The hierarchy model, parties, farms, fields, seasons, crop zones, is the structural backbone of every data relationship in the service. Many teams built their hierarchy iteratively and never wrote it down. When it came time to migrate, they had to reverse-engineer their own data structure from API exports. Export your hierarchy structure first, in a separate pass before exporting your actual data, and keep it as a reference document.
Treat preview services differently from GA services. Azure Data Manager for Agriculture was always clearly labeled as a preview. Preview services on Azure can be retired with relatively short notice, in this case, roughly five months. The rule for any preview-tier Azure service is: never build a production-critical dependency on it without an exit strategy. Always identify which GA service or independent platform you'd move to if Microsoft retired the preview.
Set up audit logging on day one. I can't tell you how many teams set up Azure Data Manager for Agriculture, did zero diagnostic settings configuration, and then had no log data to work with when issues arose months later. Diagnostic settings in Azure are opt-in. Setting them up on the day you provision any Azure resource costs nothing and saves hours of troubleshooting later.
Test satellite ingestion pipeline updates immediately after release notes drop. The November 2023 update to Azure Data Manager for Agriculture changed reprojection methods in a way that silently altered existing results. Any service that processes spatial or scientific data will go through methodology updates. Subscribe to the release notes RSS feed for any service you depend on and have a regression test that validates known-good outputs after every update.
- Export your complete hierarchy model (parties, farms, fields) as a JSON backup immediately, this is the hardest thing to reconstruct later
- Enable Azure Monitor diagnostic settings on your Data Manager instance before running any bulk export operations, so failures are logged
- Store all exported data in Azure Blob Storage with geo-redundancy enabled, not just local disk, the 30-day deletion window leaves no room for storage failures
- Test your bearer token refresh logic before running long export jobs, Azure AD tokens expire every 60 minutes, and a multi-hour bulk export will fail halfway through if you don't handle token refresh
Frequently Asked Questions About Azure Data Manager for Agriculture
What exactly is Azure Data Manager for Agriculture and what did it do?
Azure Data Manager for Agriculture was a Microsoft Azure preview service designed to help agricultural organizations bring together data from across the farming value chain, satellite imagery, weather forecasts, sensor readings, and farm operations records, in a single unified platform. It provided a standardized agriculture data model, REST APIs for powering apps, an ISV solution framework for connecting to third-party agronomy models, and, from November 2023 onward, generative AI capabilities for building agriculture copilots. The service was aimed at helping organizations drive harvest efficiency, reduce food waste, automate emissions reporting, and build sustainability insights. It was always a preview service, and Microsoft officially retired it on September 1, 2025.
Azure Data Manager for Agriculture is showing "retired", what does that actually mean for my data?
Retirement means the service no longer receives any functional or security updates, and Microsoft has stopped accepting new deployments. More critically for your data: Microsoft does not retain copies of your data after the service retires. The official policy is that Microsoft will delete all customer data 30 days after the September 1, 2025 retirement date, meaning data deletion began on approximately October 1, 2025. If you are reading this after that date and have not yet extracted your data, you should contact Microsoft Support immediately to understand your specific situation. For future reference, the official guidance was to extract all data and begin transition planning as soon as the retirement was announced.
My Azure Data Manager for Agriculture API calls keep returning HTTP 403, how do I fix it?
HTTP 403 from the Azure Data Manager for Agriculture data plane almost always means a missing AgriService role assignment, not a subscription-level permission problem. Generic Azure Contributor or Owner roles do not grant data plane access to this service. You need the AgriService Contributor, AgriService Owner, or AgriService Reader role assigned specifically at the Azure Data Manager for Agriculture resource scope, not at the subscription or resource group level. Go to your instance in the Azure portal, open Access control (IAM), click "View my access," and look specifically for roles with the "AgriService" prefix. If they're missing, add the appropriate role and wait 2–5 minutes for propagation before retrying.
My satellite imagery data looks shifted or the field boundaries don't align, what happened?
This is almost certainly caused by the reprojection method update that shipped in November 2023. Microsoft improved the satellite ingestion capability to more accurately reflect on-the-ground dimensions across the globe, which was especially impactful for farms at higher latitudes where the older method introduced visible distortion. Any satellite ingestion jobs run before that update used the old reprojection method and may produce coordinates that no longer align correctly with current map layers. The fix is to re-run your satellite ingestion jobs using the updated API and verify the new nomenclature conventions match what your downstream consumers expect. The November 2023 release notes explicitly warned that these changes "might require changes in how you consume services to ensure continuity."
Can I still get technical help for Azure Data Manager for Agriculture after retirement?
Yes, but your options are limited. Microsoft has stopped providing functional or security updates to the service, so bug fixes and new features are off the table. For billing disputes or compliance documentation needs, you can still create a support request through Microsoft Support if you have an active support plan. For technical questions about the service itself, especially data extraction and export, the best remaining resource is Microsoft Q&A, where community experts familiar with the preview service can still help. Microsoft's official guidance for the retirement period specifically called out Microsoft Q&A as the recommended channel for getting answers from community experts.
What should I migrate to now that Azure Data Manager for Agriculture is retired?
Microsoft hasn't announced a direct successor to Azure Data Manager for Agriculture at the time of this writing. Organizations that need a cloud-hosted agriculture data platform should evaluate purpose-built agri-tech platforms that offer similar data model standardization, ISV connectivity, and generative AI integration. Key capabilities to look for in a replacement are: a structured hierarchy model for organizing farm data, REST API access for app development, satellite and sensor data connectors, and an extensibility framework for third-party ISV models. For the generative AI and Copilot template capabilities specifically, Azure AI Studio or Azure OpenAI Service can serve as the underlying infrastructure for rebuilding those workflows with your own data sources, though you'll need to rebuild the agriculture-specific data orchestration layer that Azure Data Manager for Agriculture provided out of the box.