Prepare DNS and firewall prerequisites for eDig365 Reporter
Use this guide to prepare customer-owned DNS, routes, and firewall rules before installing eDig365 Reporter with the Customer network integrated deployment profile.
The Marketplace deployment uses the network resources that you select. It can restrict Storage and Key Vault through service endpoints or create private endpoints and DNS zone groups. It doesn’t enable service endpoints on customer subnets or create or change virtual network links, DNS resolvers, forwarding rules, routes, firewalls, network virtual appliances, VPN, or ExpressRoute configuration.
For the complete installation workflow, see Deploy eDig365 Reporter with customer network integration.
Prepare the network path
Provide an App Service integration subnet in the deployment region. Provide a separate private endpoint subnet when you select dependency private endpoints or private application ingress.
| Subnet | Requirement |
|---|---|
| App Service integration | Dedicated to App Service VNet Integration and delegated to Microsoft.Web/serverFarms. Attach the approved route table and network security group before installation. Enable Microsoft.Storage and Microsoft.KeyVault service endpoints when that dependency mode is selected. |
| Private endpoint | Required for dependency private endpoints or private ingress. Keep it separate from the integration subnet and allow enough capacity for the selected endpoints and growth. |
The integration subnet must be /27 or larger. /26 is recommended for operational headroom. The Marketplace deployment doesn’t alter subnet delegation, route tables, or network security groups.
Configure private DNS
When you select dependency private endpoints, create or identify these existing Azure Private DNS zones and make them selectable by the installation identity:
| Service | Private DNS zone | Required when |
|---|---|---|
| Azure Blob Storage | privatelink.blob.core.windows.net |
Dependency private endpoints |
| Azure Queue Storage | privatelink.queue.core.windows.net |
Dependency private endpoints |
| Azure Table Storage | privatelink.table.core.windows.net |
Dependency private endpoints |
| Azure Key Vault | privatelink.vaultcore.azure.net |
Dependency private endpoints |
| Azure App Service | privatelink.azurewebsites.net |
Private endpoint-only ingress |
Link each required zone to the virtual networks that must resolve the private endpoint addresses. When you use custom DNS servers, configure the corresponding Azure Private DNS resolver path or conditional forwarding. Preserve Azure private endpoint DNS resolution; don’t create public-address records that override these private names.
During deployment, eDig365 attaches DNS zone groups to the selected zones. The resulting records resolve the deployed Storage and Key Vault hosts privately. With private ingress, they also resolve the application and SCM hosts privately.
Before installation, confirm that the DNS path can resolve the required private endpoint addresses from the App Service integration subnet and from every network that needs private application access.
Choose ingress DNS
Public HTTPS ingress
The App Service public endpoint remains enabled. Dependency private DNS is required only when you select private endpoints for Storage and Key Vault.
Private endpoint-only ingress
The deployment disables public App Service access and creates an App Service private endpoint. Before installation, verify that authorized user and administrator networks can resolve and reach both:
<application-name>.azurewebsites.net<application-name>.scm.azurewebsites.net
Those names must resolve to the App Service private endpoint through privatelink.azurewebsites.net. Also ensure the authorized path can reach TCP port 443 on the private endpoint. The Marketplace deployment doesn’t provide a private access path for users or administrators.
Configure outbound routing and firewall rules
Select the egress mode that matches your network design.
| Egress mode | Customer network requirement |
|---|---|
| Direct App Service path | Public application traffic uses the App Service direct path. Storage and Key Vault traffic still uses VNet Integration and private DNS. A customer registry image pull uses VNet Integration. |
| Customer-routed through the virtual network | App Service route-all sends application and supported platform traffic through the integration subnet. Your route table and egress appliance must supply the next hop and permit all required destinations. |
For customer-routed egress, allow outbound HTTPS on TCP port 443 from the integration subnet to the following destination categories. Use FQDN-based rules where your firewall supports them; Azure service IP ranges can change.
| Destination | Requirement |
|---|---|
| Microsoft Entra sign-in and token endpoints | Allow the tenant’s Entra endpoint, *.login.microsoft.com, and *.identity.azure.net. |
| Microsoft Graph | Allow graph.microsoft.com. |
| eDig365 publisher registry | Allow the eDig365 registry hostname provided with your pull credential. |
| Azure Container Registry image delivery | When the selected registry is Azure Container Registry, allow its registry hostname, *.azurecr.io, *.data.azurecr.io, and the required Azure Storage blob endpoints. |
| Customer-managed registry | Allow its registry hostname and every HTTPS endpoint required for Registry v2 authentication, manifest retrieval, and layer retrieval. |
| Azure Monitor | When support telemetry is enabled, allow *.applicationinsights.azure.com and *.monitor.azure.com. |
| Azure platform identity and certificate operations | Allow the Azure platform endpoints required by your environment for managed identity and certificate validation. Validate the actual path with the network probe. |
With dependency private endpoints, permit the integration subnet to reach the private endpoint subnet on TCP port 443. With service endpoints, Storage and Key Vault use their public service addresses, but traffic remains on the Azure backbone and their firewalls allow only the selected integration subnet.
The deployment doesn’t configure a route table, NAT Gateway, Azure Firewall, third-party firewall, network virtual appliance, or on-premises route. Create or identify those controls and confirm they are functional before installation.
Configure an application outbound proxy when selected
The optional application outbound proxy applies only to eDig365 Reporter HTTP and HTTPS traffic. It is independent of the selected egress mode.
- Provide an unauthenticated proxy URI with a host and port, such as
http://proxy.internal.example.com:8080. - Preserve end-to-end TLS. TLS interception isn’t supported.
- Don’t include credentials or a path in the proxy URI.
- Ensure the proxy can resolve and connect to the required public destinations.
- Don’t rely on the proxy for container image pulls or other pre-container App Service platform operations. Those follow the selected image-pull and egress routing.
The deployment creates the product-managed NO_PROXY entries for loopback, link-local and managed-identity endpoints, plus the exact deployed Storage and Key Vault hosts. You can add exact hostnames, subdomain suffixes, or IP addresses. An entry such as api.internal.example.com bypasses only that host; .internal.example.com bypasses all subdomains under that suffix.
Confirm readiness before installation
Before opening Microsoft Marketplace, confirm that:
- The selected virtual networks are in the deployment region.
- The App Service integration subnet is dedicated, delegated to
Microsoft.Web/serverFarms, and has the approved route table and network security group. - The integration subnet has
Microsoft.StorageandMicrosoft.KeyVaultservice endpoints when service-endpoint dependency access is selected. - The private endpoint subnet is separate, permits private endpoints, and has sufficient capacity when dependency private endpoints or private ingress is selected.
- Each required private DNS zone exists, is linked to the necessary virtual networks, and resolves through the customer DNS path when private endpoints are selected.
- Authorized networks can resolve and reach the application and SCM hostnames when private endpoint-only ingress is selected.
- The selected outbound route permits the required HTTPS destinations. For customer-routed egress, it has a working next hop through the egress appliance.
- A selected customer registry permits trusted TLS, Registry v2 authentication, manifest retrieval, and image-layer retrieval.
- A selected proxy is unauthenticated, doesn’t intercept TLS, and can reach the required HTTPS destinations.
Resolve any DNS, route, or firewall issue before selecting Review + create. The Marketplace wizard requires an acknowledgment that the customer network prerequisites are complete.
Provide these values for Marketplace installation
Give the deployment operator the following values. They select the corresponding existing resources in the Marketplace wizard; resource IDs aren’t entered manually.
| Marketplace input | Value to provide |
|---|---|
| App Service integration virtual network and subnet name | The existing virtual network and the dedicated, delegated integration subnet name. |
| Storage and Key Vault access | Service endpoints or Private endpoints. |
| Private endpoint virtual network and subnet name | Required when dependency private endpoints or private ingress is selected. |
| Blob, Queue, Table, and Key Vault private DNS zones | Required when dependency private endpoints are selected. |
| App Service private DNS zone | The existing privatelink.azurewebsites.net zone when private endpoint-only ingress is selected. |
| Ingress mode | Public HTTPS or Private endpoint only. |
| Egress mode | Direct App Service path or Customer-routed through the virtual network. |
| Application outbound proxy | No application outbound proxy, or the unauthenticated proxy URI and any additional bypass hosts. |
| Image source | eDig365 publisher registry or Customer-managed registry. |
| Customer-managed registry | Its server name, repository, immutable tag or SHA-256 digest, and pull-only username and token. Required only for a customer-managed registry. |
The deployment operator also needs the subscription, resource group, region, application name, Microsoft Entra tenant ID, app registration client ID, initial eDig365 administrator email address, selected registry credential, and support telemetry choice. See Deploy eDig365 Reporter with customer network integration for the complete installation workflow.
Troubleshoot common failures
| Symptom | First checks |
|---|---|
| Service-endpoint dependency access is denied | Check both required service endpoints on the integration subnet and the subnet rules on Storage and Key Vault. |
| Private dependency doesn’t resolve | Check the matching private DNS zone, virtual network link, resolver path, forwarding rule, and private endpoint DNS zone group. |
| Private application or SCM hostname doesn’t resolve | Check privatelink.azurewebsites.net, private endpoint records, virtual network links, and authorized-network DNS forwarding. |
| Application can’t reach Graph or sign-in services | Check DNS, TCP port 443, firewall decisions, and the route from the integration subnet. |
| Customer registry pull fails | Check registry DNS, TLS trust, pull-only credential, Registry v2 manifest and layer access, and the selected image-pull route. |
| Proxy requests fail | Confirm that the proxy is unauthenticated, doesn’t intercept TLS, is reachable from the integration subnet, and can reach the required destinations. |