JCF INFRA

AZURE NETWORKING / LAB-003

Recovering an internal Load Balancer service

Diagnosing a timeout: from three unhealthy backends to verified responses from three IIS servers through one private frontend.

AZ-700 · M419 September 2026Recovered historical evidence

Documented outcome: Screenshots show a change from 0% to 100% healthy instances and a client test from myTestVM returning myVM1, myVM2 and myVM3.

01 / Architecture and objective

The M4 lab used an internal Azure Standard Load Balancer, three backend VMs and a client VM. Juan arrived with a deployment partly adapted with Claude’s assistance, but the private-IP test timed out.

myTestVM → 10.1.2.4:80 → myIntLoadBalancer (internal)
                       → TCP/80 rule → backend pool
                           ├─ myVM1 · 10.1.0.5 · IIS
                           ├─ myVM2 · 10.1.0.6 · IIS
                           └─ myVM3 · 10.1.0.4 · IIS
Historical administration: Azure Bastion / Run Command

Private VIP 10.1.2.4 was the service entry point, not a VM address. VM/IP mappings come from the health screenshot. The test client was inside the network environment.

02 / Adaptations and decisions

Separate application failure from load-balancer failure

The panel showed three Down targets and probe timeouts. myVM1’s VMConfig extension showed Provisioning failed: it could not download install-iis.ps1 from raw.githubusercontent.com. This identifies an installation dependency failure, not the specific route, firewall or outbound mechanism responsible.

Repair IIS before recreating infrastructure

Run Command was used to install Web-Server and write each VM name into its homepage. One repair was checked before continuing with the others. Evidence retains a successful execution and recovery to three Up targets.

Adapt the exercise to account constraints

Retained local M4 files use Standard_B1s and include separate parameter files for myVM1, myVM2 and myVM3. Juan reported changes due to account limits and Claude assistance. These files establish prepared configuration, not final deployed sizes or a universal four-vCPU quota.

Validate more than one response

The browser repeatedly displayed myVM2. Fifteen separate curl.exe invocations from myTestVM then returned all three names. Flow-based distribution does not require every browser refresh to select a different VM.

Historical validation command from myTestVM

1..15 | ForEach-Object {
    curl.exe -s --no-keepalive http://10.1.2.4
}

Transcribed from E05; not executed during this recovery. Each iteration starts a separate curl process. The screenshot establishes received names, not statistical distribution.

03 / Validation and results

What each check establishes
CheckRecorded resultBoundary
Initial state0% healthy; three DownE01 establishes the symptom, not its cause alone.
Installation extensionVMConfig download failureE02 is myVM1 evidence; the same message is not assumed for other VMs.
RepairWeb-Server: Success TrueE03 retains the script and successful myVM1 repair output.
Later state100% healthy; three UpE04 establishes observed health at that time.
Client testmyVM1 / myVM2 / myVM3 responsesE05 demonstrates all three backends responding; not failover, load or guaranteed distribution.

04 / Original evidence

Screenshots supplied during the lab and recovered from local history. With permission, publication copies were cropped to exclude personal details and unrelated interface elements. No evidence was reconstructed or AI-generated. Originals and provenance records are retained. Screenshots keep their original language.

E01 · Three Down backends and 0% healthy before repair. Account header excluded.
E01 · Three Down backends and 0% healthy before repair. Account header excluded.
E02 · VMConfig failed to download install-iis.ps1 from GitHub. Subscription identifier excluded.
E02 · VMConfig failed to download install-iis.ps1 from GitHub. Subscription identifier excluded.
E03 · IIS installation and VM-name page; myVM1 output shows Success True.
E03 · IIS installation and VM-name page; myVM1 output shows Success True.
E04 · Three Up backends and 100% healthy after repairs.
E04 · Three Up backends and 100% healthy after repairs.
E05 · Private-VIP test: fifteen invocations and responses from myVM1, myVM2 and myVM3.
E05 · Private-VIP test: fifteen invocations and responses from myVM1, myVM2 and myVM3.

05 / Scope and lessons

  • No new Azure query or test of these historical endpoints was performed.
  • The exact network cause of the download failure was not established. It is not automatically attributed to Free Trial, an NSG or missing NAT.
  • Tested failover, load resilience, uniform distribution and zone-failure tolerance are not claimed.
  • Parameter files are preparation evidence, not a substitute for exported deployment state.
  • Traffic Manager was attempted later and blocked by App Service quotas. That attempt is not part of this completed case’s outcome.

Practical lesson: A deployed VM does not guarantee an available application. Correlating extension status, service, probes and client responses avoids changing the load balancer blindly.

Provenance and references

Recovered from “Continuar preparación AZ-700”, with 19 September 2026 screenshots and M4 files. The user reported earlier work assisted by Claude; diagnosis and validation continued in ChatGPT. Documentary recovery: 16 October 2026.