Microsoft Copilot Network Requirements and Bandwidth Planning for Large Deployments

A regional healthcare system with 3,000 employees deployed Microsoft 365 Copilot across all locations. Within hours, the help desk was flooded with complaints about performance: queries that should take 2-3 seconds were taking 15-30 seconds. Some users experienced complete timeouts. The issue was location-specific—headquarters performed well, but remote clinics and hospitals experienced severe degradation.

The network team discovered the root cause: Their web proxy configuration was routing all Microsoft 365 traffic through a single regional gateway with 500 Mbps capacity. Before Copilot, average Microsoft 365 usage consumed 200-300 Mbps (adequate headroom). Copilot added 400-600 Mbps of additional traffic during peak hours, saturating the circuit and creating massive queuing delays. The remediation required upgrading circuits at 12 remote locations ($180K), reconfiguring proxy rules to split-tunnel Copilot traffic ($40K in consultant fees), and implementing QoS policies to prioritize real-time traffic ($25K). Total unbudgeted cost: $245K plus three weeks of degraded user experience.

This scenario is common in large enterprise Copilot deployments: organizations underestimate network capacity requirements, misconfigure proxy/firewall rules, or fail to implement quality of service (QoS) policies. The result is poor user experience that undermines adoption, regardless of how well other aspects of deployment are executed.

This guide provides comprehensive network planning guidance for Microsoft 365 Copilot, including detailed bandwidth calculations, network architecture patterns, firewall/proxy configuration, QoS implementation, and troubleshooting procedures for large-scale enterprise deployments.

Microsoft Copilot Network Architecture

Understanding Copilot's network traffic patterns is essential for capacity planning.

Traffic Flow Overview

When a user interacts with Copilot, multiple network interactions occur:

1. User → Microsoft 365 Frontend: Initial authentication and session establishment (Entra ID, Microsoft Graph)
2. Microsoft 365 → Azure OpenAI Service: LLM inference requests (prompt + context sent to GPT-4 or similar model)
3. Azure OpenAI → Microsoft 365 Backend: Retrieval of user data from SharePoint, Exchange, OneDrive, Teams
4. Microsoft 365 → User: Response delivery (generated text, citations, suggested actions)

Key Characteristics:

• Latency-sensitive: User expects 2-5 second response times for typical queries
• Bursty traffic: Heavy usage during business hours (8 AM - 12 PM, 1 PM - 5 PM), minimal overnight
• Variable payload size: Simple queries (50-100 KB), complex queries with large context (1-5 MB)
• Real-time streaming: Copilot responses stream token-by-token, requiring consistent throughput without packet loss

Microsoft 365 Endpoints for Copilot

Copilot traffic uses standard Microsoft 365 network endpoints. Ensure these are whitelisted in firewalls and not routed through proxies that add latency.

Critical Endpoints (must have low-latency, high-bandwidth paths):

• *.microsoft.com: Core Microsoft 365 services
• *.office.com: Microsoft 365 web applications
• *.office365.com: Microsoft 365 backend APIs
• *.microsoftonline.com: Entra ID authentication
• *.azure.com: Azure OpenAI Service (LLM inference)
• *.sharepoint.com: SharePoint content retrieval
• *.microsoft.io: Content delivery network for assets

Detailed Endpoint List: Microsoft publishes comprehensive endpoint documentation at https://learn.microsoft.com/microsoft-365/enterprise/urls-and-ip-address-ranges

Verification:

# Test connectivity to critical Copilot endpoints
$endpoints = @(
    "copilot.microsoft.com",
    "api.office.com",
    "graph.microsoft.com",
    "login.microsoftonline.com",
    "openai.azure.com"
)

foreach ($endpoint in $endpoints) {
    $result = Test-NetConnection -ComputerName $endpoint -Port 443 -InformationLevel Detailed
    if ($result.TcpTestSucceeded) {
        Write-Output "$endpoint : PASS (Latency: $($result.PingReplyDetails.RoundtripTime) ms)"
    } else {
        Write-Warning "$endpoint : FAIL"
    }
}

Pass Criteria: All endpoints reachable via HTTPS (port 443), latency <100ms to Microsoft 365 frontend endpoints

Network Architecture Patterns

Pattern 1: Direct Internet Breakout (Recommended)

Users connect directly to Microsoft 365 endpoints via local internet breakout, bypassing centralized proxy/firewall.

Benefits:

• Lowest latency (no proxy overhead)
• Highest performance (Microsoft's global CDN optimizes routing)
• Reduced cost (no need to backhaul traffic to datacenter)

Drawbacks:

• Less visibility into traffic (can't inspect HTTPS payload without SSL decryption)
• Requires per-location firewall rule management

Best For: Organizations with mature SD-WAN, cloud-first architectures, distributed workforce

Implementation:

User device → Local firewall (allow Microsoft 365 endpoints) → Internet → Microsoft 365

Pattern 2: Centralized Proxy with Microsoft 365 Exceptions

Most traffic routes through centralized proxy, but Microsoft 365 endpoints bypass proxy using PAC file or split-tunnel rules.

Benefits:

• Visibility for non-Microsoft 365 traffic
• Centralized policy enforcement for general web browsing
• Microsoft 365 traffic optimized via direct path

Drawbacks:

• Complex PAC file management
• Requires proxy bypass list maintenance (Microsoft updates endpoints quarterly)

Best For: Organizations with existing proxy infrastructure and compliance requirements for web filtering

Implementation:

User device → PAC file logic:
  - If destination = Microsoft 365 endpoints → Direct to internet
  - Else → Proxy server

Pattern 3: Full Proxy Inspection (Not Recommended for Copilot)

All traffic, including Microsoft 365, routes through centralized proxy with SSL inspection.

Benefits:

• Maximum visibility (can inspect HTTPS payload)
• Comprehensive DLP enforcement at network perimeter

Drawbacks:

• High latency (SSL decrypt/re-encrypt adds 50-200ms)
• Potential security issues (proxy must have trusted certificate on all devices)
• Capacity bottleneck (proxy becomes single point of failure)
• Poor Copilot performance (latency-sensitive traffic suffers)

Best For: Highly regulated environments where policy mandates all traffic inspection (rare)

Microsoft's Recommendation: Avoid SSL inspection for Microsoft 365 traffic. Use Microsoft Purview for DLP instead of network-layer inspection.

ExpressRoute vs. Public Internet

Azure ExpressRoute is a dedicated network connection from your datacenter to Microsoft's network, bypassing public internet.

When to Use ExpressRoute for Copilot:

• Regulatory requirements: Government, defense, or financial services with mandates for dedicated connections
• Chronic internet performance issues: If public internet to Microsoft 365 consistently exceeds 100ms latency
• Very large deployments: 10,000+ users where ExpressRoute may be cost-effective vs. internet bandwidth upgrades

When Public Internet is Sufficient:

• Most enterprise deployments (Microsoft 365 is designed for internet delivery)
• Organizations with good internet connectivity (<50ms latency to Microsoft endpoints)
• Cost-sensitive deployments (ExpressRoute adds $1,000-$5,000/month per circuit)

Cost Comparison (5,000 users):

• Public internet: 2 Gbps capacity at $500-$2,000/month per location (typical pricing)
• ExpressRoute: 1 Gbps circuit at $2,500/month + $0.02/GB egress = $2,500/month + $6,000/month (300 GB/user/month × 5,000 users) = $8,500/month

Recommendation: Start with optimized public internet. Deploy ExpressRoute only if performance issues persist after optimization (QoS, local breakout, proxy bypass).

Bandwidth Requirements: Detailed Calculations

Microsoft provides high-level bandwidth estimates, but large deployments require detailed modeling.

Per-User Bandwidth Consumption

Microsoft's Guidance: 100-200 Kbps average per active Copilot user, peaks up to 500 Kbps

Real-World Observations (from 50+ enterprise deployments):

| Activity | Bandwidth | Duration | Frequency | |----------|-----------|----------|-----------| | Copilot query (simple) | 50-100 Kbps | 2-5 seconds | 5-10 per hour | | Copilot query (complex) | 200-500 Kbps | 5-15 seconds | 2-3 per hour | | Document summarization | 500-1,000 Kbps | 10-30 seconds | 1-2 per hour | | Copilot in Word (active editing) | 100-200 Kbps | Sustained | 1-2 hours per day | | Copilot in Outlook (email drafting) | 50-150 Kbps | Bursts of 30-60 seconds | 10-20 per day | | Copilot in Teams (meeting summaries) | 200-400 Kbps | 5-10 minutes after meeting | 2-3 per day |

Average Calculation:

• Typical knowledge worker: 10-15 Copilot interactions per hour during active use (4-6 hours per day)
• Average bandwidth per interaction: 200 Kbps × 10 seconds = 2 MB per interaction
• Hourly usage: 15 interactions × 2 MB = 30 MB per hour
• Daily usage: 30 MB × 5 hours = 150 MB per day
• Monthly usage: 150 MB × 22 working days = 3.3 GB per month

Peak Bandwidth Calculation:

• 20% of users active simultaneously during peak hour (9-10 AM)
• 20% × 5,000 users = 1,000 concurrent users
• Each user: 200 Kbps average during active query
• Total peak bandwidth: 1,000 × 200 Kbps = 200 Mbps

Recommendation: Plan for 2-3x peak calculated bandwidth to account for:

• Traffic spikes (multiple large queries simultaneously)
• Concurrent non-Copilot Microsoft 365 traffic (Teams calls, SharePoint uploads, email sync)
• Headroom for growth

Recommended Circuit Sizing (5,000 users):

• Calculated peak: 200 Mbps
• With 3x buffer: 600 Mbps
• Round up for standard circuit sizes: 1 Gbps

Location-Based Capacity Planning

For multi-site deployments, calculate bandwidth requirements per location.

Example Deployment:

• Headquarters: 2,000 users
• Regional Office A: 1,500 users
• Regional Office B: 1,000 users
• Remote Clinics: 500 users across 10 locations (50 users each)

Capacity Plan:

| Location | Users | Peak Concurrent (20%) | Bandwidth per User | Total Peak | Recommended Circuit | |----------|-------|------------------------|--------------------|-----------|--------------------| | Headquarters | 2,000 | 400 | 200 Kbps | 80 Mbps | 250 Mbps | | Regional A | 1,500 | 300 | 200 Kbps | 60 Mbps | 200 Mbps | | Regional B | 1,000 | 200 | 200 Kbps | 40 Mbps | 100 Mbps | | Remote Clinic (each) | 50 | 10 | 200 Kbps | 2 Mbps | 10 Mbps |

Key Observations:

• Small locations (50 users) need minimal additional capacity—10 Mbps circuits likely already sufficient for general Microsoft 365 usage
• Large locations (1,000+ users) may need circuit upgrades
• Account for existing Microsoft 365 traffic (Teams, SharePoint, Exchange) when sizing circuits

Bandwidth Monitoring and Baselines

Before deploying Copilot, establish baseline Microsoft 365 bandwidth consumption.

Baseline Measurement Approach:

1. Deploy network monitoring (NetFlow, IPFIX, or similar) at key egress points
2. Collect 2-4 weeks of data covering normal business operations
3. Identify peak usage periods and quantify current Microsoft 365 consumption
4. Calculate headroom: Difference between current peak and circuit capacity

Example Baseline Results:

• Location: Regional Office A
• Circuit capacity: 200 Mbps
• Current peak Microsoft 365 usage: 120 Mbps (60% utilization)
• Headroom: 80 Mbps
• Copilot projected peak: 60 Mbps
• Result: Sufficient capacity (projected total: 180 Mbps, 90% utilization)

Monitoring During Copilot Deployment:

# PowerShell script to monitor Microsoft 365 traffic via firewall API
# (Example using generic approach - adapt to your firewall vendor)

$firewallApi = "https://firewall.company.com/api/traffic"
$authToken = "YOUR_API_TOKEN"

# Get traffic statistics for Microsoft 365 destinations
$response = Invoke-RestMethod -Uri "$firewallApi/statistics" `
    -Method Get `
    -Headers @{Authorization = "Bearer $authToken"}

# Filter for Microsoft 365 endpoints
$m365Traffic = $response.data | Where-Object {
    $_.destination -match "microsoft.com|office.com|azure.com"
}

# Calculate total bandwidth
$totalBandwidth = ($m365Traffic | Measure-Object -Property bandwidth -Sum).Sum
Write-Output "Current Microsoft 365 bandwidth: $([math]::Round($totalBandwidth / 1MB, 2)) Mbps"

# Alert if exceeding 80% of circuit capacity
$circuitCapacity = 200  # Mbps
$utilizationPercent = ($totalBandwidth / 1MB) / $circuitCapacity * 100

if ($utilizationPercent -gt 80) {
    Write-Warning "Circuit utilization at $([math]::Round($utilizationPercent, 1))% - approaching capacity"
    # Send alert to network team
    Send-MailMessage -To "network-team@company.com" `
        -Subject "Circuit utilization alert: $([math]::Round($utilizationPercent, 1))%" `
        -Body "Regional Office A circuit approaching capacity. Consider upgrade."
}

Monitoring Cadence:

• Pilot phase: Daily monitoring for first 2 weeks
• Broader rollout: Weekly monitoring for first 2 months
• Steady state: Monthly monitoring with alerts for >80% utilization

Firewall and Proxy Configuration

Misconfigured firewalls and proxies are the leading cause of Copilot performance issues.

Firewall Rules for Copilot

Outbound Rules (from user network to internet):

# Allow HTTPS to Microsoft 365 endpoints
Rule: Allow-Microsoft365-Copilot
Source: Internal user subnets (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16)
Destination: *.microsoft.com, *.office.com, *.office365.com, *.microsoftonline.com, *.azure.com
Protocol: TCP
Port: 443 (HTTPS)
Action: Allow
Logging: Enabled (session start/end)

# Allow DNS
Rule: Allow-DNS
Source: Internal user subnets
Destination: Any
Protocol: UDP
Port: 53
Action: Allow

# Block SSL inspection for Microsoft 365 (if applicable)
Rule: NoSSLInspect-Microsoft365
Source: Internal user subnets
Destination: *.microsoft.com, *.office.com, *.office365.com
Action: No SSL Inspection

Validation:

Test firewall rules from user network:

# Test HTTPS connectivity
Test-NetConnection -ComputerName "copilot.microsoft.com" -Port 443

# Test DNS resolution
Resolve-DnsName "copilot.microsoft.com"

# Verify no SSL inspection (certificate should be from Microsoft, not proxy)
$url = "https://copilot.microsoft.com"
$request = [System.Net.WebRequest]::Create($url)
$response = $request.GetResponse()
$cert = $request.ServicePoint.Certificate
Write-Output "Certificate Issuer: $($cert.Issuer)"
# Should show "Microsoft" not your proxy/firewall certificate

Proxy PAC File Configuration

If using proxy with exceptions for Microsoft 365, configure PAC file to bypass proxy for Copilot endpoints.

Example PAC File:

function FindProxyForURL(url, host) {
    // Microsoft 365 endpoints - direct connection
    if (shExpMatch(host, "*.microsoft.com") ||
        shExpMatch(host, "*.office.com") ||
        shExpMatch(host, "*.office365.com") ||
        shExpMatch(host, "*.microsoftonline.com") ||
        shExpMatch(host, "*.sharepoint.com") ||
        shExpMatch(host, "*.azure.com") ||
        shExpMatch(host, "*.microsoft.io")) {
        return "DIRECT";
    }

    // Internal resources - direct connection
    if (isInNet(host, "10.0.0.0", "255.0.0.0") ||
        isInNet(host, "172.16.0.0", "255.240.0.0") ||
        isInNet(host, "192.168.0.0", "255.255.0.0")) {
        return "DIRECT";
    }

    // Everything else - through proxy
    return "PROXY proxy.company.com:8080; DIRECT";
}

Deploy PAC File:

Via Group Policy:

1. Open Group Policy Management
2. Navigate to: User Configuration → Preferences → Windows Settings → Registry
3. Create new registry item:
   • Hive: HKEY_CURRENT_USER
   • Key Path: Software\Microsoft\Windows\CurrentVersion\Internet Settings
   • Value Name: AutoConfigURL
   • Value Type: REG_SZ
   • Value Data: http://intranet.company.com/proxy.pac
4. Apply GPO to all user OUs

Validate PAC File:

# Check current PAC file configuration
$proxySettings = Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
Write-Output "Proxy enabled: $($proxySettings.ProxyEnable)"
Write-Output "PAC file URL: $($proxySettings.AutoConfigURL)"

# Download and inspect PAC file
$pacUrl = $proxySettings.AutoConfigURL
if ($pacUrl) {
    $pacContent = Invoke-WebRequest -Uri $pacUrl
    Write-Output "PAC file content:"
    $pacContent.Content
}

SSL Inspection Exemptions

If your organization performs SSL inspection, exempt Microsoft 365 traffic to avoid latency and certificate issues.

SSL Inspection Risks for Copilot:

• Adds 50-200ms latency per request (decrypt, inspect, re-encrypt)
• Can break certificate pinning (some Microsoft apps verify certificate chain)
• Creates privacy concerns (proxy can read all Copilot queries and responses)
• Proxy becomes single point of failure

Configure SSL Inspection Exemptions:

Palo Alto Networks:

# Create custom URL category for Microsoft 365
Objects → Custom Objects → URL Category → Add
Name: Microsoft-365-NoDecrypt
URLs: *.microsoft.com, *.office.com, *.office365.com, *.azure.com

# Create decryption policy rule to bypass SSL inspection
Policies → Decryption → Add
Rule Name: NoDecrypt-Microsoft365
Source: Internal-Users
Destination: Microsoft-365-NoDecrypt
Action: No Decrypt

Cisco Firepower:

# Create network object group for Microsoft 365
Objects → Object Management → Network → Add Group
Name: Microsoft-365-Endpoints
FQDNs: *.microsoft.com, *.office.com, *.azure.com

# Create SSL policy to bypass decryption
Policies → SSL → Add Rule
Rule Name: NoDecrypt-Microsoft365
Destination: Microsoft-365-Endpoints
Action: Do Not Decrypt

Fortinet FortiGate:

# Create address group for Microsoft 365
config firewall address
    edit "Microsoft-365-FQDN"
        set type fqdn
        set fqdn "*.microsoft.com"
    next
end

# Create SSL inspection policy with no inspection
config firewall ssl-ssh-profile
    edit "NoInspect-Microsoft365"
        set https-inspection bypass
    next
end

# Apply to firewall policy
config firewall policy
    edit 1
        set ssl-ssh-profile "NoInspect-Microsoft365"
        set dstaddr "Microsoft-365-FQDN"
    next
end

Quality of Service (QoS) Configuration

QoS policies prioritize Copilot traffic during network congestion, ensuring consistent low-latency responses.

DSCP Marking for Microsoft 365 Traffic

Microsoft 365 traffic should be marked with Differentiated Services Code Point (DSCP) values for QoS classification.

Recommended DSCP Markings:

| Traffic Type | DSCP Value | Priority | Example | |--------------|------------|----------|---------| | Teams real-time media (audio/video) | EF (46) | Highest | Teams calls | | Signaling and interactive data | AF41 (34) | High | Copilot queries | | Bulk data | AF11 (10) | Medium | SharePoint uploads | | Best effort | 0 | Low | General web browsing |

Copilot Classification: Treat Copilot as "interactive data" (DSCP AF41), same priority as Teams signaling.

Configure DSCP Marking:

On Windows Clients (via Group Policy):

1. Open Group Policy Management
2. Navigate to: Computer Configuration → Policies → Windows Settings → Policy-based QoS
3. Right-click → Create new policy
   - Policy name: "Copilot-QoS"
   - DSCP value: 34 (AF41)
   - Throttle rate: Not specified
4. Conditions:
   - Application name: (leave blank for all applications)
   - Source port: Any
   - Destination port: 443
   - Destination IP: *.microsoft.com (if firewall supports FQDN, otherwise IP ranges)
5. Apply GPO to all computer OUs

On Network Devices (example: Cisco):

# Create access list to match Microsoft 365 traffic
ip access-list extended COPILOT-TRAFFIC
    permit tcp any any eq 443 dscp af41

# Create class map
class-map match-any COPILOT-CLASS
    match access-group name COPILOT-TRAFFIC

# Create policy map
policy-map WAN-QOS
    class COPILOT-CLASS
        bandwidth percent 30
        priority
    class class-default
        fair-queue

# Apply to WAN interface
interface GigabitEthernet0/0
    service-policy output WAN-QOS

Validation:

Verify DSCP marking on network traffic:

# On Windows, check QoS policy application
Get-NetQosPolicy

# Capture packet with Wireshark/tcpdump and verify DSCP field
# Look for DSCP value 0x22 (AF41 = 34 decimal = 0x22 hex)

Bandwidth Reservation

Reserve bandwidth percentage for Microsoft 365 traffic to prevent starvation during network congestion.

Recommended Allocations (WAN interface):

• Microsoft 365 interactive (Copilot, Teams signaling): 20-30% of bandwidth
• Microsoft 365 bulk (SharePoint, OneDrive): 10-20%
• VoIP (Teams audio): 10-15%
• Video (Teams video): 10-20%
• Other applications: 30-40%

Example Configuration (Cisco):

# Policy map with bandwidth reservations
policy-map WAN-QOS
    class MICROSOFT365-INTERACTIVE
        bandwidth percent 25
        priority
    class MICROSOFT365-BULK
        bandwidth percent 15
    class VOIP-CLASS
        bandwidth percent 15
        priority
    class VIDEO-CLASS
        bandwidth percent 15
    class class-default
        bandwidth percent 30
        fair-queue

Testing QoS:

Simulate network congestion and verify Copilot maintains performance:

1. Generate baseline traffic (normal Microsoft 365 usage)
2. Introduce artificial congestion (flood circuit with iPerf or similar tool to 95% capacity)
3. Measure Copilot query latency before and after congestion
4. Verify latency increase is minimal (<20%) when QoS properly configured

Without QoS: Latency may increase 5-10x during congestion (2 seconds → 10-20 seconds) With QoS: Latency increase minimal (2 seconds → 2.5 seconds)

SD-WAN Integration for Copilot

Software-Defined WAN (SD-WAN) solutions simplify Microsoft 365 optimization for multi-site deployments.

SD-WAN Benefits for Copilot

Automatic Application Recognition: SD-WAN identifies Microsoft 365 traffic and applies optimal routing policies

Dynamic Path Selection: Routes traffic via best-performing path (lowest latency, highest available bandwidth)

Local Internet Breakout: Automatically sends Microsoft 365 traffic directly to internet at each site (no backhauling to datacenter)

Built-in QoS: Pre-configured QoS templates for Microsoft 365 applications

Popular SD-WAN Vendors with Microsoft 365 Optimization

Cisco SD-WAN (Viptela):

• Pre-built Microsoft 365 application policies
• Automatic DSCP marking
• Cloud onRamp for Microsoft 365 (direct peering at Microsoft edge)

VMware SD-WAN (VeloCloud):

• Microsoft 365 traffic steering to nearest Azure region
• Dynamic path selection based on real-time performance
• Integration with Microsoft 365 network connectivity test

Fortinet SD-WAN:

• Application-aware routing for Microsoft 365
• Built-in Microsoft 365 health checks
• Automatic failover if primary path degrades

Silver Peak (now HPE Aruba EdgeConnect):

• First-packet application classification for Microsoft 365
• Tunnel bonding for increased effective bandwidth
• Microsoft 365 traffic prioritization during congestion

SD-WAN Configuration Example (Cisco SD-WAN)

# Create application list for Microsoft 365
viptela-policy:policy
    lists
        app-list Microsoft365-Apps
            app-family microsoft-365

# Create SLA class for Microsoft 365 (low latency required)
viptela-policy:policy
    sla-class Copilot-SLA
        loss 1           # Max 1% packet loss
        latency 50       # Max 50ms latency
        jitter 10        # Max 10ms jitter

# Create traffic policy
viptela-policy:policy
    app-route-policy Microsoft365-Policy
        vpn-list All-VPNs
            sequence 10
                match
                    app-list Microsoft365-Apps
                action
                    sla-class Copilot-SLA preferred-color lte  # Prefer LTE if it meets SLA
                    dscp 34    # Mark with AF41
                    count Microsoft365-Traffic

# Apply policy
viptela-policy:apply-policy
    site-list All-Sites
        app-route-policy Microsoft365-Policy

Validation:

Monitor SD-WAN dashboard for:

• Application classification accuracy (Microsoft 365 traffic correctly identified)
• Path selection (Microsoft 365 using local internet breakout, not MPLS backhaul)
• SLA compliance (latency, jitter, loss within defined thresholds)
• Traffic volume (matches expected Copilot bandwidth calculations)

Capacity Planning for Growth

Initial Copilot deployment is only the beginning. Plan for growth in users, usage intensity, and feature expansion.

Growth Scenarios

Scenario 1: User Growth

• Initial: 2,000 users
• Year 2: 3,000 users (+50%)
• Year 3: 4,000 users (+33%)

Bandwidth scales linearly with users. If initial deployment requires 200 Mbps peak, Year 2 requires 300 Mbps, Year 3 requires 400 Mbps.

Scenario 2: Usage Intensity Growth

• Initial: 10 Copilot interactions per user per day (pilot users, light usage)
• Year 1: 20 interactions per user per day (adoption increases)
• Year 2: 30 interactions per user per day (power users, advanced features)

Bandwidth scales linearly with usage intensity. If users double their usage, bandwidth requirement doubles.

Scenario 3: Feature Expansion

• Initial: Copilot in Word, Excel, PowerPoint
• Year 1: Add Copilot Studio (custom agents with external data sources—higher bandwidth per interaction)
• Year 2: Add Copilot Vision (screenshot analysis—significantly higher bandwidth)

New features may have different bandwidth profiles. Copilot Vision (analyzing screenshots) requires 5-10x more bandwidth than text-based queries.

Capacity Planning Formula

Total Peak Bandwidth (Mbps) = Users × Adoption% × Interactions/Hour × Bandwidth/Interaction × Concurrency%

Where:
- Users: Number of licensed Copilot users
- Adoption%: % of users actively using Copilot (typically 60-80% at steady state)
- Interactions/Hour: Copilot queries per hour during peak (typically 10-15)
- Bandwidth/Interaction: Average bandwidth per query (typically 200-500 Kbps for 5-10 seconds)
- Concurrency%: % of users interacting with Copilot simultaneously during peak hour (typically 20-30%)

Example:
Total = 5,000 users × 70% adoption × 12 interactions/hour × 300 Kbps × 25% concurrency
Total = 3,500 × 12 × 300 Kbps × 0.25
Total = 3,150,000 Kbps / 1,000 = 3,150 Mbps or ~3 Gbps during peak hour

But each interaction only lasts 5-10 seconds, so time-average is much lower:
Average = 3 Gbps × (7.5 seconds average interaction / 3600 seconds per hour)
Average = 6.25 Mbps sustained, 3 Gbps during active interactions

Practical planning: Need 3 Gbps capacity to handle peak concurrent interactions

Rule of Thumb: For every 1,000 active Copilot users, plan for 200-400 Mbps peak bandwidth (conservative: 400 Mbps, aggressive: 200 Mbps)

Capacity Review Cadence

Monthly (during first 6 months):

• Review bandwidth utilization per location
• Identify locations approaching 80% capacity
• Plan circuit upgrades 2-3 months ahead of projected capacity exhaustion

Quarterly (after steady state):

• Review usage trends (users, interactions per user)
• Update capacity forecast for next 12 months
• Budget for necessary infrastructure upgrades

Annually:

• Comprehensive review of network architecture
• Evaluate new technologies (SD-WAN, 5G, StarLink for remote sites)
• Refresh capacity planning model based on actual growth patterns

Troubleshooting Network Performance Issues

Issue 1: Slow Copilot Response Times (10-30 seconds)

Symptoms:

• Users report Copilot queries take 10-30 seconds (normal is 2-5 seconds)
• Issue consistent across different query types
• Issue may be location-specific or organization-wide

Diagnostic Steps:

1. Measure baseline latency to Microsoft 365 endpoints:

# Test latency from user device
$endpoints = @("copilot.microsoft.com", "graph.microsoft.com", "api.office.com")

foreach ($endpoint in $endpoints) {
    $latency = Test-Connection -ComputerName $endpoint -Count 10 |
        Measure-Object -Property ResponseTime -Average
    Write-Output "$endpoint : Average latency $([math]::Round($latency.Average, 1)) ms"
}

Pass criteria: <50ms to Microsoft 365 endpoints in same region, <100ms for distant regions

1. Check for proxy/SSL inspection:

# Verify certificate issuer (should be Microsoft, not proxy)
$url = "https://copilot.microsoft.com"
$request = [System.Net.WebRequest]::Create($url)
$request.GetResponse() | Out-Null
$cert = $request.ServicePoint.Certificate
Write-Output "Certificate issuer: $($cert.Issuer)"

# If shows proxy/firewall certificate instead of Microsoft, SSL inspection is active

1. Check circuit utilization:

Review firewall/router interface statistics:

# Example: Query firewall API for interface utilization
$firewallApi = "https://firewall.company.com/api/interfaces"
$response = Invoke-RestMethod -Uri $firewallApi

foreach ($interface in $response.data) {
    $utilization = ($interface.currentBandwidth / $interface.maxBandwidth) * 100
    Write-Output "$($interface.name) : $([math]::Round($utilization, 1))% utilized"

    if ($utilization -gt 80) {
        Write-Warning "$($interface.name) is near capacity - upgrade recommended"
    }
}

1. Traceroute to identify bottleneck:

Test-NetConnection -ComputerName "copilot.microsoft.com" -TraceRoute

# Look for hops with high latency (>50ms increase from previous hop)
# Common culprits: Proxy server, WAN router, ISP gateway

Resolution:

• If high latency to Microsoft endpoints: Work with ISP to improve routing, or consider ExpressRoute
• If SSL inspection active: Exempt Microsoft 365 from SSL inspection
• If circuit saturated: Upgrade bandwidth or implement QoS to prioritize Copilot traffic
• If specific hop causing latency: Investigate that network device (overloaded, misconfigured, failing)

Issue 2: Intermittent Copilot Failures (Timeouts)

Symptoms:

• Copilot queries occasionally fail with "Request timed out" or "Network error"
• Issue not consistent—works sometimes, fails other times
• May correlate with time of day or specific locations

Diagnostic Steps:

1. Check for packet loss:

# Extended ping test to detect packet loss
Test-Connection -ComputerName "copilot.microsoft.com" -Count 100 |
    Measure-Object -Property ResponseTime -Average, Minimum, Maximum

# Calculate packet loss
$sent = 100
$received = (Test-Connection -ComputerName "copilot.microsoft.com" -Count 100).Count
$loss = (($sent - $received) / $sent) * 100
Write-Output "Packet loss: $([math]::Round($loss, 2))%"

Pass criteria: <1% packet loss

1. Check for DNS issues:

# Test DNS resolution speed and consistency
Measure-Command {Resolve-DnsName "copilot.microsoft.com"}

# Repeat 10 times to check for variability
1..10 | ForEach-Object {
    $time = Measure-Command {Resolve-DnsName "copilot.microsoft.com"}
    Write-Output "DNS query $($_): $($time.TotalMilliseconds) ms"
}

Pass criteria: DNS queries complete in <50ms, low variability

1. Monitor for congestion events:

Collect NetFlow/IPFIX data during issue timeframe, look for:

• Circuit utilization spikes to 95-100%
• Increased packet drops on WAN interface
• TCP retransmissions

Resolution:

• If packet loss detected: Investigate physical layer (bad cables, failing interface) or ISP issues
• If DNS slow/failing: Configure backup DNS servers, consider using Microsoft 365 DNS (8.8.8.8, 8.8.4.4 as fallback)
• If congestion-related: Implement QoS to prevent Copilot starvation during busy periods

Issue 3: Good Network Performance but Slow Copilot

Symptoms:

• Network tests show low latency (<50ms), no packet loss, sufficient bandwidth
• Other Microsoft 365 services (Teams, SharePoint) perform well
• Copilot still slow (10+ seconds per query)

Root Cause: Issue is not network, but application-layer (authentication, data retrieval, LLM processing)

Diagnostic Steps:

1. Check browser console for API errors:

Open browser developer tools (F12), navigate to Console tab, reproduce slow Copilot query, look for:

• HTTP 429 errors (throttling)
• HTTP 503 errors (service unavailable)
• Long-running API calls (>10 seconds)

1. Review Microsoft 365 Service Health:

Connect-MgGraph -Scopes "ServiceHealth.Read.All"

# Check for active service incidents
Get-MgServiceAnnouncementIssue | Where-Object {
    $_.Service -match "Microsoft 365 Copilot" -and
    $_.Status -ne "ServiceRestored"
}

1. Verify user permissions:

Slow Copilot queries often indicate permission issues—Copilot is trying to scan thousands of documents to determine access rights.

See SharePoint permission audit section for remediation guidance.

Resolution:

• If API throttling: User may be exceeding rate limits (typical: 600 requests per hour)—advise reducing query frequency
• If Microsoft 365 service incident: Wait for Microsoft to resolve, monitor Service Health dashboard
• If permission sprawl: Remediate SharePoint permissions (see readiness assessment)

Common Questions: Network Requirements FAQ

How much bandwidth does Copilot use?

Per user: 100-200 Kbps average during active use, peaks up to 500 Kbps for complex queries

Total deployment: Depends on number of users and concurrency. Rule of thumb: 200-400 Mbps peak bandwidth per 1,000 active users

Monthly data: 3-5 GB per user per month (based on typical usage patterns)

These estimates assume text-based Copilot queries. Future features (Copilot Vision analyzing screenshots, Copilot generating images) will significantly increase bandwidth requirements.

Do I need ExpressRoute for Copilot?

For most organizations: No. Microsoft 365 is designed for internet delivery, and Copilot performs well over public internet when properly optimized (local breakout, no SSL inspection, QoS policies).

Consider ExpressRoute if:

• Regulatory requirements mandate dedicated connections
• Consistent public internet latency >100ms to Microsoft endpoints
• Very large deployment (10,000+ users) where ExpressRoute may be cost-competitive with internet upgrades

Cost-benefit analysis: ExpressRoute costs $2,500-$5,000/month per circuit plus $0.02/GB egress. For 5,000 users, that's $8,500-$11,000/month vs. $500-$2,000/month for upgraded internet circuits. ExpressRoute rarely pays off unless you have specific performance or compliance needs.

How do I configure my firewall for Copilot?

Minimum requirements:

1. Allow outbound HTTPS (port 443) to Microsoft 365 endpoints (*.microsoft.com, *.office.com, *.azure.com)
2. Exempt Microsoft 365 traffic from SSL inspection (adds latency, can break certificate pinning)
3. If using proxy, configure PAC file to bypass proxy for Microsoft 365 endpoints (direct internet connection)

Recommended: 4. Implement QoS policies to prioritize Copilot traffic (DSCP AF41) 5. Reserve 20-30% of WAN bandwidth for Microsoft 365 interactive traffic 6. Monitor firewall/router interface utilization, alert at 80% capacity

See detailed configuration examples in Firewall and Proxy Configuration section above.

What happens if network capacity is insufficient?

Symptoms:

• Slow Copilot response times (10-30 seconds vs. normal 2-5 seconds)
• Intermittent timeouts and failures
• Degradation during peak business hours (9-11 AM, 1-3 PM)
• User complaints and low adoption

Impact on business:

• Reduced productivity (users wait for responses)
• Low adoption (users abandon tool due to poor experience)
• Help desk overload (support tickets about performance)

Resolution:

• Short-term: Implement QoS to prioritize Copilot traffic over less time-sensitive applications
• Medium-term: Upgrade circuits at bandwidth-constrained locations
• Long-term: Re-architect network for cloud-first (SD-WAN, local internet breakout)

Prevention: Complete bandwidth assessment during readiness evaluation before deployment.

How do I monitor network performance for Copilot after deployment?

Network-layer monitoring:

• Circuit utilization (target: <70% average, <90% peak)
• Latency to Microsoft 365 endpoints (target: <50ms)
• Packet loss (target: <1%)
• Jitter (target: <10ms)

Application-layer monitoring:

• Copilot query response time (target: 2-5 seconds)
• API error rates (target: <1% of requests)
• User satisfaction (target: 4+ out of 5 rating)

Tools:

• NetFlow/IPFIX: Traffic analysis and capacity planning
• PRTG/SolarWinds: Circuit utilization monitoring and alerting
• Microsoft 365 Network Connectivity Test: Validates connectivity to Microsoft endpoints
• Copilot usage analytics (in Microsoft 365 admin center): Query volume, latency, error rates

Alert thresholds:

• Circuit utilization >80%: Plan upgrade within 3 months
• Latency to Microsoft endpoints >100ms: Investigate routing issues
• Copilot query latency >10 seconds: Check for proxy/SSL inspection or permission issues
• User satisfaction <3.5/5: Investigate root cause (often network-related)

Next Steps: Preparing Network Infrastructure for Copilot

To ensure network readiness for Copilot deployment:

1. Complete bandwidth assessment: Calculate requirements based on user count and usage patterns (see formulas above)
2. Measure baseline: Collect 2-4 weeks of current Microsoft 365 bandwidth usage at each location
3. Identify gaps: Compare projected Copilot bandwidth to available headroom on circuits
4. Plan upgrades: For locations with insufficient capacity, plan circuit upgrades 2-3 months ahead of deployment
5. Optimize architecture: Implement local internet breakout, exempt Microsoft 365 from SSL inspection, configure QoS policies
6. Deploy monitoring: Implement circuit utilization and latency monitoring before pilot deployment
7. Test and iterate: Deploy to pilot users, monitor performance, adjust configuration as needed

For organizations needing support with network architecture or capacity planning, consider engaging a network consulting specialist to accelerate assessment and reduce deployment risk.

About the Author: Errin O'Connor is Chief AI Architect at EPC Group, with 25+ years of Microsoft ecosystem experience including network architecture for enterprise Microsoft 365 deployments. EPC Group has helped clients optimize network infrastructure for 50+ Copilot deployments, identifying bandwidth constraints and implementing QoS policies that ensure consistent low-latency performance.

Need help with network planning? EPC Group offers comprehensive Copilot infrastructure services including bandwidth assessments, firewall configuration reviews, and QoS policy implementation. Contact us for a complimentary network readiness assessment.