networking
6 TopicsMicrosoft Edge Enterprise — Intermittent Blue Coat Proxy Authentication Prompt
Product: Microsoft Edge for Business / Microsoft Edge Enterprise Component: Proxy authentication, HTTP networking and integrated authentication Operating system: Windows 11 Enterprise Proxy: Blue Coat / Broadcom forward proxy, port 8080 Proxy authentication configuration: Basic Auth/ IWARealm exact authentication method to be confirmed Affected browser: Microsoft Edge for Business Comparison browser: Mozilla Firefox, where the same behaviour has not been observed Impact: Intermittent interruption of browsing and loss of access to existing tabs until the user reauthenticates We are experiencing intermittent, unexpected proxy authentication prompts in Microsoft Edge for Business. The dialog states: Sign in to access this site. The proxy http://[bluecoat-host-url]:8080 requires a username and password. Your connection to this site is not secure. The prompt appears sporadically, sometimes while the browser is idle or while tabs displaying otherwise idle ServiceNow, deepl etc. pages cannot be accessed until user reauthenticates with autofill if proxy password is saved in order to be able to access those sites again. No explicit navigation or user interaction is necessarily taking place when the dialog appears. This behaviour was not observed previously and has become noticeable more recently especially since the migration of a lot of our workloads to the microsoft cloud. Firefox does not appear to exhibit the same symptom under comparable. We suspect that a background request, a new or reused proxy connection, proxy-session reauthentication, or an incomplete integrated-authentication exchange may be triggering the prompt. However, we have not yet identified the exact request or established whether the root cause is Edge, the proxy configuration, PAC routing, or the authentication infrastructure. usage conditions. Edge should silently authenticate to the configured enterprise proxy through the organisation's approved authentication mechanism, without unexpectedly displaying a credential prompt during normal browsing or background activity.54Views0likes1CommentNetwork connectivity test TCP Connection results unreliable
My team has spent the last 2 business days trying to get the https://connectivity.office.com/ TCP connection test to complete successfully to appease the Microsoft Unified Support Team. They don't want to take our MS Teams crash diags until they see SSL Interception Detection and TCP connection tests passing successfully. We can't get TCP connection tests to pass, we get one of the following: Success Attempt #1 Success, Attempt #2 Failure Any number of errors to unblock URLs such as (but not limited to) ocsp.digicert.com,ocspx.digicert.com,ocsp.omniroot.com,su.symcb.com,sr.symcb.com,sd.symcb.com,s1.symcb.com,sa.symcb.com We figured it was something with the corporate network but that's not the case. Last night we had about 50 employees try this test from their home (personal) computers that have no connection to our corporation. The TCP Connection test fails on home (consumer) PCs. What's the story with this TCP Connection check?1.3KViews2likes2CommentsWebsocket 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.1.4KViews0likes3CommentsNot able to receive emails
i user mail https://outlook.office.com/mail @lenk-frozen.com Proble receive emails BY @hungaca.com Use mail https://outlook.office.com/mail Proble Message Mail last week form mailto:dattx@hungca.com i check dns hungca.com 112.213.89.11 i tracert proble time out Please Check Email microsoft to microsoft Lost receive emails ? Email Lost date tuesday, April 19,2022 3.41 PM ??681Views0likes0CommentsTeams Network Assessment Tool Is Good But...
The https://www.microsoft.com/en-us/download/details.aspx?id=103017 is very good (kudos to the developers) but it is only good for testing locally at a single client machine. We run an entirely distributed workforce (i.e. no office), how would I test every client machine (without obviously manually installing/running on every client!)? Note: this is a pre-Teams rollout test - no CQD analytics. Any ideas? Maybe a Sysinternals remote deploy/execution or is there a webapp that does the same thing that clients could just visit e.g. the https://connectivity.office.com/ webapp downloads an exe for similar purposes?4KViews2likes1CommentMS Teams and connectivity errors
PaulAndrew Once I run the connectivity tool I m getting the following errors/issues under the Team connectivity, do you know why and the recommendations or can you pleasde direct me to a resource thta I can find the answers. 1. Media connectivity (audio, video, and application sharing)- Media connectivity is not reachable worldaz.tr.teams.microsoft.com is not reachable using Protocol UDP and Port 3478 2. Packet loss -Teams call was not successful 3. Latency -Teams call was not successful 4. Jitter -Teams call was not successful Connectivity 1. TCP connection Unblock URL: xxx.xxx.com, Test FQDN(s) used were: XX.XXX.com Unblock URL: smtp.office365.com Test FQDN(s) used were: smtp.office365.com 2. SSL interception detection No errors Thanks.14KViews1like2Comments