Mobile Plans moves to the web
Windows is retiring the built-in Mobile Plans app to simplify how you connect your PC to mobile data. Instead of using Mobile Plans app to buy or manage cellular plans, you’ll use your web browser and the Windows Settings app going forward. This change means a more integrated experience: no extra app installations, just a direct link between Windows and your mobile operator’s website. In this post, we’ll outline why this change is happening, what the new experience looks like, and how it benefits both consumers and mobile operators. A more streamlined web-based experience Direct purchase on operator websites: Instead of launching an app, you’ll purchase and activate your cellular data plan directly on your mobile operator’s website. This change to a web-centric and operator-driven model better aligns with familiar experiences on other platforms. From Windows, when you want to add a mobile plan, you’ll navigate to your carrier’s web portal in your browser. Each operator will handle their own sign-up and payment flow. No separate app needed: Windows 11 has new built-in functionality to make this web-based activation seamless, meaning one less app installed on your PC. When you purchase a plan on the site of participating carriers, Windows might prompt you via the Settings app to share your device’s cellular identifiers (like EID, IMEI) with the operator. With your consent, these details are securely passed to the carrier, so they can automatically provision your eSIM without you needing to type in codes or scan QR images. You can then download and start using cellular data right away. By using industry-standard web flows, HTTPS, and confirmation steps, this system remains streamlined and secure. Timeline of the transition Windows already supports activating eSIM using the web, via QR codes, and manual entry. The new experience to share your device’s cellular identifiers is available for Windows Insiders and will release publicly in the last half of 2025. Mobile operators will be adding support throughout the next year. The You can continue using the Mobile Plans app until February 27, 2026. After that date, the app will be retired and you may uninstall it, and references to the app in Windows will be removed. If you face issues with this transition, please contact your mobile operator or visit their website to buy and manage eSIM data plans for your PC. What it means for users For most Windows users, this change should be convenient: connecting your device to a mobile network should be as easy as buying something online. If you already have an active mobile plan, you don’t need to take any action. Here are the key impacts: No loss of cellular functionality: Existing cellular features on Windows remain intact. Any eSIM profiles or data plans you’ve already activated on your PC will continue to work normally. Any plans you purchased through Mobile Plans will continue working, but you’ll need to go to the operator’s website to manage them. Other ways of activating eSIM (like scanning a QR code from a carrier or manually entering activation codes) will continue to be supported just as before. Mobile Plans app will be going away: You will see a message within the app about the end of support date. After that date, the app will be retired and may be uninstalled. The app will be removed from the Microsoft Store, and any links to open the app from within Windows will be removed. Seamless user experience: If you have a laptop or tablet with LTE/5G and eSIM support, you’ll no longer need the Mobile Plans app. Instead, you can go directly to your carrier’s online sign-up page and then follow the Windows Settings prompts to install the eSIM profile and get connected. Where to get and manage plans now: After the transition, to sign up for a new cellular plan on your PC, directly visit your mobile operator’s website and look for their section on activating an eSIM for Windows devices. After the transition, documentation will be updated to guide you through the new flow. What it means for mobile operators Microsoft has reached out to mobile operators participating in the Mobile Plans app, providing them the necessary details to transition to this new model. Operator enablement: Carriers are adapting their systems to support eSIM activation for Windows PCs via web. This involves adding an option on their websites to initiate the Windows activation flow and handle the secure sharing of device identifiers and eSIM profiles. Microsoft is providing technical guidance so that each operator’s implementation meets the necessary criteria for a seamless user experience. Information on how to download eSIM profile is available here: Use a QR code or URI link to download an eSIM profile. Trials and feedback: Starting in June 2025, selected operator partners began trialing the new flow with Microsoft. These trials allow operators to test the end-to-end process (from website to Windows device) and ensure any issues are ironed out before broad launch. All mobile operators with Windows data plan offerings are encouraged to participate in testing so that they’re ready by the time the app is retired. Please reach out to your local Microsoft representative with questions. Removal from Mobile Operator Portal and COSA profiles: Following the retirement of the app, the Mobile Operator Portal will be updated to remove "Mobile Plans" as an option when creating a new draft. The COSA definition for enabling GetBalance will also be removed from all the provider profiles. Only the two entries “SupportDataMarketPlace” and “MobilePlansIdentifier” will be removed. Updating “View My Account” links: In the current Windows UI, some carriers integrated with Mobile Plans have a “View my account” link in the network settings or Quick Settings. Those links used to point to the Mobile Plans app. Going forward, those need to point to the carrier’s own account management webpage. Operators should submit updated configurations (via COSA, the provisioning database) to ensure their customers can easily click from Windows UI to the correct web page for account info. More information is available here: Microsoft Mobile Operator Configuration Portal Guide. Continued collaboration: This change enables the operators to have more control when building and providing a great activation experience. Microsoft will continue to work in partnership with mobile operators to ensure a seamless transition. Next steps The retirement of the Mobile Plans app is a move toward a simpler, web-powered, and more streamlined future for Windows connectivity. For users, it means one less app and an easier way to get your device online. For operators, it gives them direct control of the customer purchase experience. Over the coming months, Microsoft will roll out the necessary Windows updates and work with carriers to finalize the new system. Keep an eye on the official Windows release notes and your carrier’s communications for announcements of support for the new eSIM activation flow. In the meantime, if you’re a user looking to add cellular service to your Windows PC, you can continue to use the Mobile Plans app until it’s retired or check your operator’s website for information. Many operators already allow eSIM activation via QR code or manual entry, which is what the new flow streamlines. We’re confident that moving to a web-centric solution will provide a smoother, more consistent connectivity experience for everyone. Thank you for being part of this journey to simplify Windows networking! Additional information Microsoft Mobile Operator Configuration Portal Guide Use a QR code or URI link to download an eSIM profileLesson Learned #533: Intermittent Azure SQL Database Connectivity and Authentication Issues
While working on a recent service request, we helped a customer troubleshoot intermittent connection and authentication failures when accessing Azure SQL Database using Active Directory (Entra ID) authentication from a Java-based application using HikariCP with JDBC/ODBC. They got the following error: com.zaxxer.hikari.pool.HikariPool$PoolInitializationException: Failed to initialize pool: Failed to authenticate.. Request was throttled according to instructions from STS. Retry in 29701 ms. java.sql.SQLTransientConnectionException: HikariPool-application1 - Connection is not available, request timed out after The first insight was focusing in the error message: Request was throttled according to instructions from STS. Retry in 29701 ms. This message seems it is returned by the Azure Active Directory Security Token Service (STS) when the client is sending too many token requests in a short period of time, exceeding the allowed threshold. We don't have all the details about, but, in high-concurrency environments (e.g., multiple threads, large connection pool) causes each thread to independently request a new token and we could reach a limit in this service, even, if the connection pool retries frequently or fails authentication, the number of token requests can spike. This is the reason, that HikariCP tries to initialize or refresh connections quickly, as many threads attempt to connect at once, and all trigger token requests simultaneously, STS throttling is reached. In order to avoid this situation, could be different topics, like, ensure our application caches tokens and reuses them across threads, using Managed Identity, increase the retry after delay, or perhaps, depending on HikariCP configuration, pre-warm connections gradually. Of course, discuss with your EntraID administration is other option.Lessons Learned #534: Azure SQL Database Connections with Managed Identity and Python ODBC
We worked on a service request that our customer trying to enable their Python application, hosted on Azure App Service, to connect securely to Azure SQL Database using a user-assigned managed identity. They attempted to use the Microsoft ODBC Driver for SQL Server with the managed identity for authentication. During our troubleshooting process we found several issues/error messages causing by an incorrect settings in the connection string: The initial connection string used the 'ActiveDirectoryInteractive' authentication method, which is not compatible with managed identities. The correct approach is to use 'ActiveDirectoryMsi' or 'ActiveDirectoryManagedIdentity' for system/user-assigned managed identities. Switching to 'ActiveDirectoryMsi' led to a pyodbc error: pyodbc.Error: (FA005, [FA005] [Microsoft][ODBC Driver 18 for SQL Server]Cannot use Access Token with any of the following options: Authentication, Integrated Security, User, Password. (0) (SQLDriverConnect)). The FA005 error message indicated a mismatch between the use of an access token and the connection string properties. Specifically, when passing an access token, the connection string must not include conflicting authentication parameters such as User, Password, or Integrated Security.Lesson Learned #532:Power BI Refresh Failure Due to Connection Pool Exhaustion in Azure SQL Database
We've been working on a service request that a customer experienced frequent failures when refreshing Power BI reports connected to an Azure SQL Database. The error message indicated a problem with acquiring connections from the data source pool, leading to unsuccessful report refreshes. We found the following error message: A request for a connection from the data source pool could not be granted. Retrying the evaluation may solve the issue. The exception was raised by the IDbCommand interface. Analyzing the details of the case, we found that the issue occurred regardless of whether Entra ID or SQL authentication was used, we don't have issue at Azure SQL Database level and not login error, but, we identified a high number of simultaneous connection attempts from Power BI to Azure SQL Database. We also reviewed the configuration of Power BI Desktop and noted that it loads multiple tables in parallel during refresh operations. This behavior triggers a surge of concurrent connections to the database, which in this scenario resulted in exhaustion of the connection pool at the application layer. We suggested to reduce the parallel table loading setting in Power BI Desktop, using File > Options and settings > Options > Data Load and Under Parallel loading of tables. Later adjusted the setting to a higher value to find a balance between performance and stability.Lesson Learned #359: TCP Provider: Error code 0x68 (104) (SQLExecDirectW)
Today, we got a service request that our customer faced the following error message connecting to the database: (pyodbc.OperationalError) ('08S01', '[08S01] [Microsoft][ODBC Driver 18 for SQL Server]TCP Provider: Error code 0x68 (104) (SQLExecDirectW)'). This customer is using Python in a Linux environment. Following I would like to share my lessons learned about this error message.Lesson Learned #522: Troubleshooting TLS and Cipher Suites with Python connecting to Azure SQL DB
A few days ago, we were working on a service request where our customer was experiencing several issues connecting to Azure SQL Database due to TLS version and cipher suite mismatches when using Python and ODBC Driver 18. Although we were able to get that information through a network trace, I would like to share things that I learned. Using the library SSL in Python allows to establish a TLS/SSL context where I can control the TLS version and specify or inspect the cipher suite. Here’s a small script that demonstrates how to connect to the Azure SQL Gateway over port 1433 and inspect the TLS configuration: import ssl import socket #ServerName to connect (Only Gateway) host = 'servername.database.windows.net' port = 1433 # TLS context context = ssl.create_default_context() print("Python uses:", ssl.OPENSSL_VERSION) context.minimum_version = ssl.TLSVersion.TLSv1_2 context.maximum_version = ssl.TLSVersion.TLSv1_2 context.check_hostname = True context.verify_mode = ssl.CERT_REQUIRED context.load_default_certs() # Testing the connection. with socket.create_connection((host, port)) as sock: with context.wrap_socket(sock, server_hostname=host) as ssock: print("TLS connection established.") print("TLS version:", ssock.version()) print("Cipher suite:", ssock.cipher()) # CN (Common Name) cert = ssock.getpeercert() try: cn = dict(x[0] for x in cert['subject'])['commonName'] print(f"\n Certificate CN: {cn}") except Exception as e: print(" Error extracting CN:", e) print("Valid from :", cert.get('notBefore')) print("Valid until:", cert.get('notAfter')) Using this script I was able to: Enforce a specific TLS version by setting minimum_version and maximum_version , for example, (1.2 or 1.3) Retrieve the cipher suite negotiated. Inspect the details of the certificate. Enjoy!Lesson Learned #520: Troubleshooting Azure SQL Database Redirect Connection over Private Endpoint
A few days ago, we handled an interesting support case where a customer encountered the following connection error when using sqlcmd to connect to their Azure SQL Database "Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login timeout expired. Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : TCP Provider: Error code 0x102. Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to servername.database.windows.net (Redirected: servername.database.windows.net\xxxx8165ccxxx,6188). Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online." At first glance, what immediately caught our attention was the port number mentioned in the error 6188. This is not the typical 1433 port that SQL Server usually listens on. Additionally, the message referenced a "Redirected" connection, which gave us the first strong clue. We asked the customer to run the following commands for diagnostics steps: ping servername.database.windows.net to identify the IP address resolved for the Azure SQL Database Server, returning a private IP: 10.1.0.200. nslookup servername.database.windows.net to confirm whether the resolution was happening through a custom DNS or public DNS. ifconfig -a to determine the local IP address of the client, which was 10.1.0.10 (our customer is using Linux environment - RedHat) With all this information in hand, we asked the customer to open a terminal on their Linux machine and execute sudo tcpdump -i eth0 host 10.1.0.200 meanwhile they are attempting to connect using another terminal with sqlcmd and we observed that the sqlcmd was: First making a request to the port 1433 that is expected And then immediately attempting a second connection to port 6188 on the same private IP. It was during this second connection attempt that the timeout occurred. After it, based on the port and the message we asked to our customer what type of connection has this server and they reported Redirect. We explained in Azure SQL, when Redirect mode is enabled, the client: Connects to the gateway on port 1433 Receives a redirection response with a new target IP and dynamic port (e.g., 6188) Attempts a new connection to the private endpoint using this port We reviewed the connection configuration and confirmed that Redirect mode was enabled. After speaking with the customer's networking and security team, we discovered that their firewall rules were blocking outbound connections to dynamic ports like 6188. We proposed two alternative solutions: Option 1: Adjust Firewall Rules Allow outbound traffic from the client’s IP (10.1.0.10) to the Private Endpoint IP (10.1.0.200) for the required range of ports used by Azure SQL in Redirect mode. This keeps the benefits of Redirect mode: Lower latency Direct database access via Private Link Reduced dependence on Azure Gateway Option 2: Switch to Proxy Mode Change the Azure SQL Server's connection policy to Proxy, which forces all traffic through port 1433 only. This is simpler for environments where security rules restrict dynamic port ranges, but it may introduce slightly higher latency. In this case, the customer opted to update the VNet's NSG and outbound firewall rules to allow the necessary range of ports for the Private Endpoint. This allowed them to retain the benefits of Redirect mode while maintaining secure, high-performance connectivity to their Azure SQL Database.Lesson Learned #215: Hands-On-Labs: Communication link failed error message using ODBC.
We used to have cases where our customer faced the following error messages like following: ERROR [08S01] [Microsoft][ODBC Driver 17 for SQL Server]TCP Provider: An existing connection was forcibly closed by the remote host. ERROR [08S01] [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure In this video below we going to provide us some insights about it.
