Fix Dynamics 365 Remote Assist Connection & Setup Issues

Let's establish a clear baseline. Microsoft's official requirements for Dynamics 365 Remote Assist on HoloLens specify a minimum of 1.5 Mbps up/down for peer-to-peer HD video calling at 1080p/30fps. To actually get that quality reliably, without call degradation or pixelation, you want 4–5 Mbps up/down available and dedicated to the device.

Notice that caveat "even 4–5 Mbps up/down doesn't guarantee 1080p video calling at full quality" on first-generation HoloLens. If you're running original HoloLens (not HoloLens 2), video quality will be constrained by the hardware itself, not just the network. Set expectations accordingly.

To actually test this properly from your environment:

# From a Windows device on the same network segment as the HoloLens:
# Run this PowerShell command to check network interface speed
Get-NetAdapter | Select-Object Name, LinkSpeed, Status

# To test latency to Microsoft's infrastructure:
Test-NetConnection -ComputerName teams.microsoft.com -Port 443
Test-NetConnection -ComputerName login.microsoftonline.com -Port 443

You want to see latency under 150ms to those endpoints. High latency (200ms+) causes audio sync issues and makes the spatial annotation features in Remote Assist nearly unusable because the hologram positions lag behind real-world movement.

Also check jitter and packet loss if you can get access to your network monitoring tools. Packet loss above 1% will noticeably degrade video quality even if your raw bandwidth is fine. A call that drops packets erratically is worse than a call with consistent lower bandwidth.

If you confirm bandwidth is sufficient and latency is acceptable, move to Step 2. If bandwidth is the bottleneck, coordinate with your network team, the fix lives there, not in the app.

This step trips up almost every enterprise deployment. Corporate firewalls block outbound traffic by default, and unless your network team has explicitly allowlisted these endpoints, Dynamics 365 Remote Assist will fail in ways that look like app bugs but are actually network blocks.

Here are the exact endpoints that must be reachable from the device running Remote Assist. Work with your network or firewall team to add these to your outbound allowlist:

# Teams (core calling infrastructure)
*.registrar.skype.com        UDP: 3478, 3479, 3480, 3481
*.teams.microsoft.com        UDP: 3478, 3479, 3480, 3481

# Authentication (Microsoft Entra / identity)
login.microsoft.com          TCP: 80, 443
login.microsoftonline.com    TCP: 80, 443
login.live.com               TCP: 80, 443
sts.windows.net              TCP: 80, 443

# Microsoft Graph API
graph.microsoft.com          TCP: 80, 443

# Enterprise Configuration Service
ecs.office.com               TCP: 80, 443

# Dynamics Services
*.crm.dynamics.com           TCP: 80, 443

# SharePoint/OneDrive (for file sharing and snapshots)
*.sharepoint.com             TCP: 80, 443

# Connection Test
*.msftconnecttest.com        TCP: 80, 443

Pay particular attention to the UDP ports 3478–3481 for Teams. Many firewalls are configured to block all UDP traffic outbound, which kills the real-time media stream entirely. Authentication may succeed (TCP 443 is typically open) but the actual video call media can't establish. This creates a confusing symptom where you can sign in, see contacts, start a call, but the video never connects or shows only a black screen.

If you're in a US Government Community Cloud (GCC) environment, you have additional URL requirements on top of these. You'll need to add endpoints from the Office 365 U.S. Government GCC High endpoints list, the Dynamics 365 US Government endpoints, and Power Apps US Government endpoints. Contact your GCC tenant administrator to get the current specific URLs, as these change more frequently than the standard commercial endpoints.

After updating your firewall rules, restart the HoloLens completely (power off, power on, don't just put it to sleep) and attempt a test call. A clean connection after that restart confirms the firewall was the issue.

Licensing is the silent killer of Dynamics 365 Remote Assist deployments. The app will install, it will appear to sign in, and then it will fail when you try to use core features, all because the license assignment is wrong, incomplete, or assigned to the wrong account.

Here's the exact process to verify and fix license assignment:

1. Sign in to admin.microsoft.com with your global admin or license admin Microsoft Entra account.
2. In the left navigation, go to Users > Active users.
3. Search for the user experiencing the Remote Assist problem and click their name.
4. Select the Licenses and apps tab.
5. Look for the Dynamics 365 Remote Assist license in the list. If it's not checked, check it and click Save changes.
6. If the license isn't available in the list at all, you need to purchase it first or confirm it's been allocated to your tenant.

One thing that catches organizations off guard: the account used on the HoloLens device must be the same Microsoft Entra account that has the license assigned. If someone sets up the HoloLens with a personal Microsoft account or a different organizational account, the license check will fail even if you've correctly licensed a different account in the same tenant.

If you're distributing the Remote Assist app through Microsoft Store for Business, verify in the Store for Business admin portal that the app has been assigned to the correct organizational group and that the user's Entra account is a member of that group. A common error here is assigning the app to a security group that the target user isn't actually a member of, it looks right in the portal but the user never receives the app.

After correcting the license assignment, give it 15–30 minutes for license propagation, then sign out of Remote Assist on the HoloLens, sign back in, and test. License changes aren't always instantaneous across Microsoft's systems.

Getting your wireless infrastructure right is the difference between a Dynamics 365 Remote Assist deployment that works reliably day after day and one that you're constantly fighting. The good news: a handful of specific changes make a dramatic difference.

Force 5 GHz exclusively. Create a dedicated SSID for HoloLens devices that broadcasts only on the 5 GHz band. Disable 2.4 GHz for this SSID entirely. The 5 GHz band has significantly more available channels, far less interference from neighboring networks and non-Wi-Fi devices (microwaves, Bluetooth, IoT devices all crowd the 2.4 GHz spectrum), and delivers the consistent low-latency throughput that video calling needs. This isn't a suggestion, for production Remote Assist deployments, treat it as a hard requirement.

Use a router or AP with MU-MIMO capability. Multi-user, multiple-input, multiple-output (MU-MIMO) technology allows your access point to communicate with multiple devices simultaneously rather than sequentially. On a busy shop floor with multiple HoloLens devices, legacy access points without MU-MIMO will create contention that shows up as intermittent call drops and variable video quality even when raw bandwidth tests fine.

To check and configure these settings on your access point, exact navigation varies by vendor, but you're looking for:

# On a Cisco Catalyst AP (example, verify against your firmware version):
# In Cisco WLC: Wireless > Access Points > [AP Name] > 802.11b/g/n
# Set 2.4 GHz Radio Admin Status: Disabled (for the dedicated HoloLens SSID)
# Enable MU-MIMO under Advanced Settings

# For a dedicated HoloLens SSID on Meraki (example):
# Wireless > SSIDs > [SSID Name] > Radio Settings
# Min. bitrate: 12 Mbps (prevents slow devices from monopolizing airtime)
# Band selection: 5 GHz only

Also consider QoS (Quality of Service) policies that prioritize UDP traffic from the HoloLens MAC addresses or subnet. Since Remote Assist video runs over UDP 3478–3481 to Teams infrastructure, marking that traffic as high-priority in your network QoS policy prevents it from getting queued behind bulk file transfers or backup jobs running on the same network.

After making wireless changes, monitor the first several calls using your AP's client statistics view. You're looking for consistent signal strength above -65 dBm, negligible retry rates (under 5%), and no channel contention alerts.

Once you've made fixes, don't just eyeball it, use Microsoft's built-in tools to confirm that call quality is actually good, not just "seems okay." This step is especially important in enterprise deployments where you need to demonstrate to stakeholders that the environment is production-ready.

Teams Call Analytics gives you per-user, per-call data. Since Dynamics 365 Remote Assist calls run over the Teams infrastructure, every Remote Assist call appears in Call Analytics. To access it:

1. Go to the Microsoft Teams admin center at admin.teams.microsoft.com.
2. Navigate to Users > Manage users.
3. Search for the HoloLens user and click their name.
4. Select the Meetings & calls tab.
5. Click on any recent Remote Assist session to see detailed call quality metrics.

You want to see jitter under 30ms, packet loss under 1%, and round-trip time under 150ms. If any of those numbers are consistently outside those ranges, you have a network infrastructure problem that the previous steps should address.

Call Quality Dashboard (CQD) is the fleet-level view, useful when you have multiple HoloLens devices deployed across a facility and want to identify which devices, which locations, or which time windows have consistently poor quality. Access it at cqd.teams.microsoft.com.

# PowerShell: Export Teams call records for analysis
# Install the Teams PowerShell module if needed:
Install-Module -Name MicrosoftTeams -Force

# Connect with admin credentials:
Connect-MicrosoftTeams

# Pull call records for a specific user (last 30 days):
Get-CsUserSession -Identity "user@yourdomain.com" | 
  Where-Object {$_.StartTime -gt (Get-Date).AddDays(-30)} |
  Select-Object StartTime, EndTime, QualityClassification, MediaQuality |
  Export-Csv -Path "C:\RemoteAssistCallQuality.csv" -NoTypeInformation

After running calls through this analysis, you'll have objective data to confirm whether your fixes worked or whether there are remaining network issues that need attention. Keep this data, it's also useful for reporting to Microsoft Support if you need to escalate a persistent problem.