Use Test Connection to check the saved Azure connection before configuring a server offering. Interpret its individual checks rather than treating the headline as permission to deploy every VM size.

Run the intended check

Open PD Modules → Azure VM and choose Test Connection after saving the provider account. The module-level test resolves the first available account for this module; it does not use whichever customer service or offering you last viewed. With multiple accounts, confirm the selected association before drawing conclusions.

Record the time and a redacted result. The check makes reads; a VM does not need to be created for this procedure. Do not repeatedly attempt provisioning to diagnose a failed credential test.

Distinguish authentication and permissions

A valid tenant, client and secret are needed to sign in. The test also checks the registration state of Microsoft.Compute and Microsoft.Network, then tries a subscription resource-group read. An app with read access can pass that read without having the write permissions needed to create resources.

Ask the Azure administrator to verify the intended app’s Contributor assignment and scope separately. For a provider-registration message, have them review the named namespace under the subscription’s Resource providers and wait for registration to complete before testing again. Do not treat every registration error as a bad secret or broadly disable security controls.

An invalid-secret result calls for checking the secret Value, not its ID. An application-not-found result calls for checking the tenant/client pair. Preserve an exact redacted error code when asking for help; do not paste the secret into an error report.

Interpret the quota detail

The connection test attempts to show total regional vCPU usage for the module’s default region. It is not a per-offering test of the selected VM family in every region. That extra read can fail without making the connection test fail, so missing quota detail is not confirmation of sufficient quota.

Check the intended deployment region and VM family’s limits with the Azure administrator before offering a size. Available quota, SKU eligibility and actual provider capacity are different constraints. A menu entry or total regional headroom alone does not prove that a particular deployment will succeed.

Review expiry and the next step

If the saved credential includes its expiry date, review any notice returned by the module. A notice is not automatic credential rotation or proof that an email reminder will reach your team. Keep the actual secret expiry in your normal maintenance process.

After resolving an issue, repeat the relevant connection check and then review the offering’s selected account and defaults. Do not include credential JSON or private account identifiers.

See the PD Azure VM WHMCS guide for related setup, or explore PD Azure VM.