Automating the Azure Resource Inventory tool

Hi ,

Thanks for reaching out to Microsoft Q&A.

Nothing is “broken” in your setup. Azure Automation is simply not a good fit for large scale ARI runs due to module limitations and payload caps. The practical solution is to run this via a Hybrid Runbook Worker or VM, where you control modules and avoid these sandbox constraints.

imo, you are hitting 2 separate issues, both common when running Resource Inventory inside Azure Automation.

1. Start-ThreadJob not recognized This is not a runtime version problem. Azure Automation sandboxes do not include the ThreadJob module by default. ARI relies on it for parallel execution.

What is happening:

• Start-ThreadJob comes from the ThreadJob PowerShell module
• Azure Automation runbooks (even PS 7.x) often run in a constrained environment without it

What to do:

• Import ThreadJob module explicitly into your Automation Account (from PSGallery)
• Or modify ARI scripts to fallback to Start-Job (less efficient but works)
• Or run this via Hybrid Worker (recommended for ARI scale scenarios)

2. ResponsePayloadTooLarge from Search-AzGraph This is a hard limit from Azure Resource Graph.

What is happening:

• Your query is returning >16 MB (limit is ~16 MB)
• ARI is trying to pull too much data in one shot

What to do:

• Limit scope aggressively:
  • Use fewer subscriptions per run
    • Filter resource types (e.g., exclude diagnostics, policies, etc.)
• Enable proper pagination:
  • ARI already uses -SkipToken, but payload is still too large per page
• Reduce columns in query (customize ARI queries if needed)  

Please 'Upvote'(Thumbs-up) and 'Accept' as answer if the reply was helpful. This will be benefitting other community members who face the same issue.

Hello Steve Harrison

Thank you for posting your query on Microsoft Q&A platform.

1. Start-ThreadJob is not available in Azure Automation sandboxes

The Start-ThreadJob cmdlet is not a built‑in PowerShell feature. It is provided by the Microsoft.PowerShell.ThreadJob module.

While this module works in local PowerShell 7 executions, Azure Automation does not guarantee availability of this module in the cloud sandbox, unless it is explicitly imported into the Runtime Environment.

Additionally, Azure Automation sandboxes do not fully support background threading/job patterns that depend on Start-Job or Start-ThreadJob. This is a documented limitation of the sandbox execution model.

Official references:

Azure Automation runbooks run inside a sandbox with feature and resource limitations https://learn.microsoft.com/azure/automation/automation-runbook-execution

Microsoft recommends Hybrid Runbook Workers when scripts require advanced execution capabilities or long‑running/background operations https://learn.microsoft.com/azure/automation/automation-runbook-execution#hybrid-runbook-worker

Because ARI explicitly uses Start-ThreadJob in automation mode, this limitation surfaces as: “The term ‘Start-ThreadJob’ is not recognized…”

This is expected behavior in Azure Automation sandboxes, not a misconfiguration on your side.

2. Search-AzGraph – ResponsePayloadTooLarge (Azure Resource Graph limit) : If a query returns too much data in a single page, the service fails with: ResponsePayloadTooLarge – Please query less data at a time and use pagination.

Even when using -SubscriptionId, ARI queries can still exceed this limit in:

• resource-dense subscriptions
• advisory / policy / security datasets
• tenant-wide executions

As a resolution please Run ARI on a Hybrid Runbook Worker (or a VM)

Reference: Hybrid Runbook Worker for complex or long‑running runbooks: https://learn.microsoft.com/azure/automation/automation-runbook-execution#hybrid-runbook-worker

If helpful, the ARI automation documentation is available here for reference: https://github.com/microsoft/ARI/blob/main/docs/advanced/automation.md

Thanks,

Suchitra.