Expand Your Readiness Checks

The official readiness script is a good start, but it has a blind spot in regards to checking for outbound connectivity: redirect chains. When an endpoint redirects to another domain that’s blocked, the script just throws “Error: not expected” without telling you what’s actually being blocked.

That’s why I built a custom diagnostic tool – to trace those redirect chains and tell you exactly which domain is causing the problem.

Real-World Example: The Redirect Chain Problem

Let me show you why custom diagnostics possibly matter. I ran into this when troubleshooting a blocked endpoint – the readiness script told me login.windows.net was failing, but it didn’t tell me why.

Here’s what I did to test this

To simulate a corporate firewall that blocks outbound connectivity by default, I blocked office.com locally. Since login.windows.net redirects there, this shows how the readiness script handles blocked redirect targets:

# Block office.com outbound
sudo iptables -A OUTPUT -p tcp -m string --string "office.com" --algo bm -j REJECT
​
# Run readiness script with network parameter
sudo ./mst-readiness.sh network

What you’ll see

• login.windows.net – Error: not expected
• No mention of office.com anywhere

The problem

• login.windows.net redirects to office.com (which is what’s actually blocked!)

What I built instead

So I built my own tool that actually follows redirect chains and tells you what’s broken. Here’s what it does differently:

• Spots HTTP redirects (301/302) and tests where they’re going
• Uses the same curl flags as the Microsoft script (-L for following redirects)
• Tests each backend IP individually
• Tells you which host in the redirect chain is blocked
• Gives you specific domains to whitelist instead of generic errors

Custom Diagnostic Tool

Remove the block when done testing

sudo iptables -D OUTPUT -p tcp -m string --string "office.com" --algo bm -j REJECT

ENJOY 🙂