What is the reasoning behind to block Azure Local deployment validation if the NIC is using an inbox driver?

Question

Build: 2505

I am trying to deploy an Azure Local cluster (single node) on a Dell PowerEdge R640 with an onboard NIC, QLogic 577xx/578xx 10 Gb Ethernet BCM57800. The validation blocks me saying I am using an inbox driver. Dell haven't released a newer driver that supports 23H2. More details here: https://dell.github.io/azurestack-docs/docs/hci/supportmatrix/2412/14g-15g_hci/

This wasn't the case with 2504, I was able to successfully deploy without being blocked. Can you please confirm if this a new check added to block deployment? Is there a way around it? This is a just a single node with RDMA disabled, on the selected network adapter, I was expecting this to pass through. What is the justification in this scenario where customers want to be able to do POC on their existing HW. Screenshot 2025-06-26 095859.png

Answer 1

Hi Jayanth Dattatri YKB,

Yes, you're absolutely right in observing a behavioral change in Build 2505 compared to 2504. Test fails because you are still using the Windows “in-box” driver, i.e. the generic one provided by Microsoft. For Azure Local or Azure Stack HCI this type of driver is not supported: you need the official Intel driver or, even better, the one provided by your OEM (Dell, HPE, Lenovo etc.) so that it shows as DriverProvider = Intel or equivalent. Until you change it, the validation will continue to fail (the Adapter inbox driver check step).

Build 2505 enforces stricter validation for networking drivers, specifically blocking inbox drivers, including for QLogic/BCM57800-based NICs, even when RDMA is disabled and the setup is single-node.

This was not enforced in build 2504, which allowed you to proceed — and this is a deliberate change in build 2505+. The check applies regardless of RDMA status or cluster size. Microsoft's documentation confirms no exceptions for POC scenarios

https://learn.microsoft.com/en-us/azure/azure-local/whats-new?view=azloc-2505
Driver Requirements

Inbox drivers are not supported for use with Azure Local. To identify if your adapter is using an inbox driver, run the following cmdlet. An adapter is using an inbox driver if the DriverProvider property is Microsoft.

https://learn.microsoft.com/en-us/azure/azure-local/concepts/host-network-requirements?view=azloc-2505#driver-requirements

Get-NetAdapter -Name <AdapterName> | Select *Driver*

You could technically re-use Build 2504 for POC purposes only, but this is not recommended for long-term or supported deployment, as:

• It's preview
• Not getting updates or support lifecycle alignment

Reach out to Dell Enterprise Support and request a 23H2-compatible WHCP driver for BCM57800.

Microsoft has been pushing hardware + driver compliance as a key requirement for all production deployments since HCI 21H2, but 23H2 enforces it more strictly.

I remind you that without the right driver Azure Local blocks key features such as RDMA, Dynamic VMMQ and SR-IOV, and that driver+firmware pairing is essential to avoid finding yourself with a card in reduced compatibility.

Once everything is fixed, the test passes and you can continue with the cluster deployment.

Please let me know if you have any further queries!

If the information is helpful, please click "upvote" to let us know!

Answer 2

Hi @Mounika Reddy Anumandla
Thank you for the detailed explanation. I will try to reach out to Dell. But I doubt if they have any plans to support 23H2 on 14G. This in my opinion is in the right direction in terms of ensuring certified drivers for 23H2. But this certainly makes it difficult to bring up a demo or a POC environment. I am not sure you're aware, even the nested virtualization (Using MS Lab) is blocked because of an issue with machine onboarding via Azure Arc. During the boostrap process using "Invoke-AzStackHciArcInitialization" command, the command fails saying "Image recipe validation tests failed.". See image attached. So this totally blocks the Demo/POC environments.