Forum Widgets
Latest Discussions
Optimizing Customer Network Connectivity for #Microsoft 365 Copilot
Network connectivity page in M365 admin center is the go-to place for tenant, network security administrators to review health and readiness of customer network connectivity setup essential for M365 applications. Problem statement Customers blocking WebSocket connections in their network infrastructure leads to broken experience for M365 Copilot users. Copilot uses WebSocket and tenant admins have no visibility into the failed WebSocket connections for their users, rendering the customer network setup not ready for Copilot roll out. Users with WebSocket connection failure will have a broken Copilot experience, here is a glimpse. We are pleased to announce the following new features in M365 admin center that are available to all customers. Admins can now view Service health notifications in Microsoft 365 admin center for Network insights detected for their tenant. They may also receive an email if opted-in to receive email notifications. The service health notification has a deep link that takes them directly to the detected network insight for their tenant, they will receive one notification per insight detected. Detected network insights include failed network connections for M365 Copilot, this public article documents the three network insights we detect Microsoft 365 Network Insights - Microsoft 365 Enterprise | Microsoft Learn Failed HTTPS connections for Unified domains *.cloud.microsoft, *.static.microsoft, *.usercontent.microsoft Failed WebSocket connections for *.cloud.microsoft Network Intermediation (TLS break and inspect) impacting performance I received a Service health notification for WebSocket or HTTPS connection failures, what should I do? Within the Service health notification there is a hyperlink that directly takes you to the Insights page in Network Connectivity. You can also go to the Insights page and click on the network insight, this shows the locations for which the insight has been detected, click on any location to review the location specific details and summary, the location summary provides you information like egress IP addresses (your source IPs from where we see connection failures) for this location. More information available in this video. 1. Visibility into failed network connections for M365 Copilot Tenant admins can now see in Microsoft 365 admin center (Microsoft 365 network connectivity - Microsoft 365 admin center) when their network impacts user connections to M365 apps, including WebSocket connections for M365 Copilot. The new report shows failure rate percentage, also known as the error rate percentage, for failed HTTPS and WebSocket connections to customer facing M365 Unified domains such as *.cloud.microsoft, *.static.microsoft, and *.usercontent.microsoft. A high error rate in this report indicates blocked network connections that impacts connectivity for various M365 applications and calls for immediate action from the tenant admin to allow blocked connections. 2. Visibility into user network latency for M365 Copilot Tenant admins can now view the network assessment points for Microsoft 365 Copilot, the assessment points are based on the network latency experienced by Copilot users. The lower the network latency, the higher the network assessment points for Microsoft 365 Copilot, providing a clear picture for tenant admins about the high network latency experienced by their users for M365 Copilot. In addition to the above, we recently announced M365 network connectivity test tool for individual users to test and validate if they successfully meet the network connectivity requirements for M365 Copilot. Additional reading references: Learn more about the connections blockers report Learn more about network assessments Learn more about M365 admin center network connectivity
Trace route from M365 (Teams) to my public IP
Hi, We are troubleshooting a voice packet loss issue in Tokyo and we've been able to force our outbound traffic to use a particular provider above IX peering and another provider. How do i see what route the return traffic (from Microsoft) is taking as there could be a few different routes? thanks,
A Record not providing Microsoft IP when migrating from GoDaddy. Need Root Cause
We are in the process of migrating 15 domains underneath 1 master tenant. The first few went fine but we ran into an issue where the A record was not created and email would not go through. I know the first thing you will think of are all the basics (blacklist, proper DNS records, misspellings, typos, etc) but understand that if it were that simple we wouldn't be posting. We even registered with MXToolbox to walk through all the steps and possibilities and it all pointed to one thing. In the below picture where we now have an IP address with an associated A Record it at first said "No Record Found" under the IP Address column. Didn't matter what we did on our end this ip address would not appear. The next thing people say is, well that's not a Microsoft address and Microsoft doesn't create those even though a DNS lookup says otherwise. So imagine our confusion when Microsoft said it's DNS on the client side and not a Microsoft issue. 8 days later with still no email we finally deleted the account and reregistered under a personal tenant. Immediately we got an A record, reverse PTR and IP address and email. Deleted and put back on the original tenant and now we have the ip that you see above and without us changing any configurations on the client side or with the hosting provider; just waited for it to finish replicating in the Admin portal after moving and it worked. We get that you have to work through the steps to get to the problem but it seems as if we couldn't get anyone to take the steps to the next level when the steps aren't working. Our focus now is that we need a root cause and for someone to at least understand that this is so not a typical scenario. We need this escalated to an Engineer to help us figure out root cause or to provide a way to escalate (we are a Gold Partner and willing to pay) without being told to be patient while the client can't access email for over a week. The client is losing trust in Microsoft and it's hard for us to defend at this point. We have 10 more migrations and are nervous that we will be stuck in the same situation.Migration from GoDaddy
Wondering if anyone has some suggestions with how to get around this error: "Enabling customization is not allowed because the Organization is currently being upgraded." We are trying to move a customer from GoDaddy to native Office 365 and when we are trying to implement the Application Impersonation feature and "Enable Customization" via Powershell. There have been no changes to the tenant that we are aware of as the end user wouldn't know how to do anything. I'm concerned that we might have to do the migration manually as from what i've read this would be a Microsoft backend fix and well i'm sure this will be super difficult if we have to go via GoDaddy (as it's currently their tenant in their iteration of Office365) to get any back end changes. Any feedback would be welcomed!Microsoft 365 network connectivity test for Microsoft 365 Copilot Generally Available
I am thrilled to announce that the Microsoft 365 network connectivity test for Microsoft 365 Copilot is now generally available worldwide. Now all the customers can run the most comprehensive connectivity test of the history from https://connectivity.m365.cloud.microsoft . ✌️😁❤️ This release also includes two improvements from the user experience perspective: Enhancing the sign-in experience for smoother user interactions (like SSO) and providing more user-friendly guidance for saving report data. As a result, we can also measure tenant information with sign-in users, giving us better insights into the business impact of the tool. We also fixed a bug in the rich client that previously blocked the test process due to firewall warnings, increasing the completion rate and performance of the tests.
