Forum Widgets
Latest Discussions
Released the full version of M365 connectivity test tool (MCT) in GCC environment
I am pleased to announce that we have successfully released the full version of the M365 connectivity test tool (MCT) in the GCC environment today. This investment will ensure excellent network connectivity and user experience across all clouds, including around 5 millions users in GCC. You can find the updated public documentation at [here] and the table below shows the feature comparison across all clouds. Please let us know if you have questions, thanks
Websocket connections to critical Microsoft 365 domains
We continue to get warnings on our tenant regarding Websocket connectivity errors. Full message states: We've detected WebSocket Secure (WSS) failures to the following unified domains. I can't publish the wildcarded URLs here, but you'll know the ones I mean from your M365 admin networking connectivity insights page. I don't understand this as we effectively have those domains whitelisted/bypassing https inspection etc and everything seems to be working as normal. Nothing has been changed as far I'm aware. Anyone else seen this warning in their tenancy? Anything else we can check or try to sort the issue. Or is it just something to note?? We have a support ticket in - but on doing the initial check nothing is showing up. Our networking team have confirmed with me that the connection sends data to Microsoft uninspected. For that reason, it shouldn’t cause the websocket errors that are being reported.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.
