Connectivity test script

When troubleshooting a Turbo360 private hosting installation, connectivity failures between the installation virtual machine and required Azure PaaS resources are one of the most common root causes. This article explains why these failures occur and provides a PowerShell connectivity test script you can run directly from the installation virtual machine to verify reachability.

Business value

Running this script immediately after deployment confirms that DNS resolution and network routing are working correctly for all required Turbo360 resources. It removes guesswork from early-stage troubleshooting by pinpointing which resource is unreachable and whether the response IP falls within the expected private VNet range.

How it works

After deploying Turbo360 and connecting it to a virtual network via private endpoints and VNet integration, incorrect DNS settings for PaaS resources are a common source of connectivity issues. The script tests each required Turbo360 resource by attempting a TCP connection on port 443 and then validating that the response IP address falls within the expected VNet IP range. Each resource is tested in sequence and the result — success or failure — is written to the console with color-coded output.

The script tests the following resources:

• Storage account

• SQL Server

• Processor function app

• Document generation function app

• Chart generation function app

• Web app

Before running the script, update the resource name variables at the bottom to match your environment, and set $expectedStartIpAddress to the IP prefix of your VNet.

Ping resources from installation virtual machine

Run the script below from the installation virtual machine to test whether all required resources are reachable and responding from the expected private IP range.

Update the resource name variables at the bottom of the script to match your environment before running.

function Test-MyConnection([string] $endpoint, [int] $port, [string] $expectedStartIpAddress){

    Write-Host ""
    Write-Host "Testing Connection"
    Write-Host "`tEndpoint: " $endpoint
    Write-Host "`tPort: " $port
    
    $pingResult = Test-NetConnection -ComputerName $endpoint -Port $port
    
    # Assert that the endpoint is reachable
    if($pingResult.TcpTestSucceeded -eq $true){
        Write-Host "`t`t[+] Connection Succeeded" -ForegroundColor Green

        if($pingResult.RemoteAddress.ToString().StartsWith($expectedStartIpAddress)){
            Write-Host "`t`t[+] Response IP address Succeeded" -ForegroundColor Green
        }
        else {
            Write-Host "`t`t[-] Response IP address Failed" -ForegroundColor Red
            Write-Host "`t`t`tResponse IP address is: " $pingResult.RemoteAddress.ToString()
        } 
    }
    else {
        Write-Host "`t`t[-] Connection Failed" -ForegroundColor Red
    }    
}

# Please update the below resource names to the correct ones for your environment
$storageAccountName = "mst360strpoc.blob.core.windows.net"
$sqlServerName = "ms-t360-sql-svr-poc.database.windows.net"
$processorFunctionApp = "ms-t360-func-processor-poc.azurewebsites.net"
$docGenFunctionApp = "ms-t360-func-docgen-poc.azurewebsites.net"
$chartGenFunctionApp = "ms-t360-func-chartgen-poc.azurewebsites.net"
$webAppFunctionApp = "ms-t360-webapp-poc.azurewebsites.net"

# Set the expected IP prefix to validate that responses come from within the VNet
$expectedStartIpAddress = "10.59" # Tests that the response IP is a local VNet address

Test-MyConnection -endpoint $storageAccountName -port 443 -expectedStartIpAddress $expectedStartIpAddress
Test-MyConnection -endpoint $sqlServerName -port 443 -expectedStartIpAddress $expectedStartIpAddress
Test-MyConnection -endpoint $processorFunctionApp -port 443 -expectedStartIpAddress $expectedStartIpAddress
Test-MyConnection -endpoint $docGenFunctionApp -port 443 -expectedStartIpAddress $expectedStartIpAddress
Test-MyConnection -endpoint $chartGenFunctionApp -port 443 -expectedStartIpAddress $expectedStartIpAddress
Test-MyConnection -endpoint $webAppFunctionApp -port 443 -expectedStartIpAddress $expectedStartIpAddress

Troubleshooting

1. Connection Failed for one or more resources
   Cause: The private endpoint for the resource is not correctly configured, or the VNet DNS zone is not linked to the VNet.
   Fix: Verify that a private endpoint exists for the resource and that the associated private DNS zone is linked to the virtual network. Check the DNS zone records to confirm the resource resolves to a private IP.

2. Response IP address Failed — response IP is a public address
   Cause: DNS is resolving the resource to its public IP instead of the private endpoint IP. This is the most common symptom of a misconfigured or missing private DNS zone.
   Fix: Confirm the private DNS zone is linked to the VNet. If the installation virtual machine uses a custom DNS server, verify it is forwarding Azure DNS queries to the Azure DNS resolver (168.63.129.16).

3. Script runs but no output appears for a resource
   Cause: The resource name variable was not updated before running the script, or the placeholder value does not resolve.
   Fix: Update all resource name variables at the bottom of the script to match the actual resource hostnames in your environment before running.

4. Connection Succeeded but IP validation fails for only the function apps
   Cause: Function apps may have a separate private endpoint or subnet configuration from the storage account and SQL Server.
   Fix: Confirm that private endpoints are configured individually for each function app, and that the DNS zone records for azurewebsites.net are present in the private DNS zone.

5. Test-NetConnection is not recognized
   Cause: The script requires Windows PowerShell or PowerShell 5.1+. It will not run on PowerShell Core (6+) without the NetTCPIP module available.
   Fix: Run the script from Windows PowerShell on the installation virtual machine, not from a cross-platform PowerShell session.

Related articles

• SMTP connectivity