Webview2 exe missing after edge update
After the recent edge update, the webview2 exe is not updated together. C:\Program Files (x86)\Microsoft\Edge\Application\151.0.4129.59\msedgewebview2.exe is missing. This breaks webview2 apps on Windows. Is there some change to location of webview2? Any new API to get the location of the new webview2, or this is a genuine bug that need to be resolved by Microsoft?How Mesh Systems Builds on Azure IoT Hub and Azure IoT Operations to Accelerate Industrial AI
Manufacturers generate vast amounts of operational data, yet its complexity and fragmentation across historians, Operational Technology (OT) systems, and cloud platforms can slow AI adoption at scale. As organizations invest in AI to enhance productivity, quality, and decision making, the ability to connect and contextualize operational data becomes critical. Azure IoT Hub, Azure IoT Operations, and Mesh address this challenge together, spanning the full path from device connectivity to actionable AI-powered insights. Mesh brings deep Azure IoT platform experience and a practical path to industrial AI, with MeshCloud built on Azure IoT Hub, an open-source .NET Akri framework for Azure IoT Operations, and MeshInsights delivering generative AI-powered operational intelligence. This expertise is backed by a long history with Azure; Mesh launched its first IoT solution on Azure in private preview in 2009 and remained an early adopter of every major Azure IoT service since. Together, Azure IoT Hub, Azure IoT Operations, and Mesh give manufacturers a streamlined way to unify operational data and apply AI where it matters most. Unlocking legacy data with Mesh's Akri Connector Industrial organizations often struggle to modernize operations because critical operational data sits isolated inside historians and legacy Operational Technology (OT) systems. Many manufacturers are also wary of integrations that create new dependencies and limit future flexibility. Azure IoT Operations addresses this through an open architecture built around Akri, connecting industrial data sources while preserving interoperability across hardware and software environments. Mesh built on this foundation with its Akri Historian Connector, bringing historian and legacy operational data into Azure IoT Operations through prebuilt connectivity rather than source-by-source integration work. The result is faster access to operational data ready for analytics, AI, and industrial automation. The key features of this connector include: Restart-safe data continuity: Manufacturers can trust that operational data keeps flowing even through outages or restarts, with no data loss and no time spent recovering or reprocessing data. Secure, flexible authentication: Modern and legacy industrial systems connect under one security model, meeting enterprise-grade authentication standards without restructuring existing infrastructure. A foundation other connectors can be built on: The underlying framework handles the heavy lifting, so teams only need to build what's unique to each new OT data source. This means faster time to value for every new data source. Built in alignment with Azure IoT Operations roadmap: The connector stays up to date automatically, as new Azure IoT Operations features become available. This means manufacturers have access to the latest capabilities as the platform evolves. Together, Mesh and Azure IoT Operations give organizations a production-ready path from the shop floor into Azure IoT Operations and onward to Microsoft Fabric. Delivering Scalable Connected Products with Azure IoT Hub and MeshCloud MeshCloud helps manufacturers move from connected product pilots to fleet scale deployments faster by providing a platform build on Azure IoT Hub and other Azure native services. Azure IoT Hub provides per-device identity, support for MQTT, AMQP, and HTTPS, and built-in capabilities like device twins, direct methods, and rules-based message routing. Azure Device Provisioning Service (DPS) extends this foundation with zero-touch, just-in-time onboarding using X.509, TPM, or symmetric key attestation. Mesh operates as one cohesive engineering practice across the full connected product lifecycle, delivering hardware, firmware, wireless, edge, and cloud integration natively for Azure IoT Hub and Azure IoT Operations. That end-to-end scope is what MeshCloud, their Azure-native connected product platform, brings together. MeshCloud embeds Azure IoT Hub and DPS into an Azure-native connected product platform, giving organizations a faster path to connected product delivery without sacrificing control, scale, or solution ownership. The platform comes together across four layers: Edge to cloud: Connected devices, from MCU controllers to tablets and phones, register and authenticate through DPS and connect securely to IoT Hub, giving organizations a direct, secure line from shop floor to enterprise systems. Messaging and command: Event Hubs and Container Apps move telemetry and commands between devices and the cloud, with asset and ontology data exposed for digital twin management and device control. IT and operations: Azure Monitor, OpenTelemetry, Microsoft Entra, and Application Gateway bring platform observability, identity management, and secure ingress together, equipping IT and operations teams with a unified way to manage and secure the environment. Analytics and visualization: Telemetry flows into Azure Data Explorer and Microsoft Fabric for processing and storage, with Grafana, Power BI, and a Device Health UI giving teams fleet-wide visibility. This architecture enables organizations to move from pilot projects to fleet-scale deployments using Azure-native services, while maintaining interoperability across devices, connectivity protocols, and analytics platforms. For manufacturers, this means less time integrating infrastructure and more time delivering operational insights, connected services, and AI-powered workflows. Advancing Industrial Intelligence with MeshInsights As organizations connect more assets and operational systems, the next challenge becomes turning information into consistent actions and decisions. Microsoft Azure provides the cloud, data, and AI foundation for intelligent operational workflows, while giving organizations control over their data and business processes. Mesh extends this foundation through MeshInsights. MeshInsights is Mesh's AI agent offering for connected-product manufacturers. Mesh works with organizations to define a specific operational decision worth automating, such as classifying an alert or determining the right service response, and builds an evaluation standard from real telemetry, service history, and expert-validated examples. AI agents are then developed and measured against that standard, acting automatically on high-confidence cases and routing the rest to the organization's own experts. This extends connected systems beyond monitoring and reporting into trusted, auditable operational decisions. By combining Azure IoT platform services with MeshInsights, Mesh helps organizations move from connected infrastructure to autonomous, AI-driven action without changing where their data lives or who owns the architecture. Why This Matters Industrial transformation increasingly depends on strong collaboration between hyperscale cloud platforms and ecosystem partners who bring operational expertise, deployment acceleration, and industry-specific engineering capabilities. Mesh Systems demonstrates how partners can build differentiated value on top of Azure IoT platform services while helping organizations accelerate deployment timelines, standardize industrial data architectures, and operationalize AI across connected environments. Organizations are already putting this value to work in everyday operations. BUNN's cloud-connected coffee machines now give technicians a head start before every service call. As Kurt Powell, Executive Vice President at BUNN, put it: "With this solution, we know exactly which component to fix before we get there." WLS Lighting Systems has turned that same visibility into measurable savings at scale. Built on MeshCloud and Azure IoT, WLS's netLiNK gives property owners remote monitoring and control over individual light fixtures. Kevin Fletcher, President National Accounts at WLS, shared that the company has saved customers a little over $50 million in electrical costs since bringing netLiNK to market. Together, Azure IoT Hub, Azure IoT Operations, and Mesh Systems help manufacturers reduce integration complexity and operationalize industrial data, creating a foundation for AI driven operations spanning plant, edge, and cloud. The result: manufacturers spend less time on integration and more time improving productivity, resiliency, and decision making across their operations. Learn More Explore Mesh Systems solutions on Azure Marketplace: Microsoft Marketplace | cloud solutions, AI apps, and agents Read customer success stories: https://meshsystems.com/case-study-eaton-1/ Learn more about Azure IoT Operations: https://azure.microsoft.com/products/iot-operations/
Edge version 150 JavaScript speechSynthesis.getVoices() undefined voices
For the past few days JavaScript speechSynthesis has had a problem in Edge browser. Sometimes it gets the proper list of voices but most of the time it returns: "Microsoft undefined Online (Natural) - undefined" for every single Natural voice. It then uses the default voice (Microsoft David) for speaking the utterance. Can you fix this bug? Edge Version 150.0.4078.83 (Official build) (64-bit) Thank you.
Edge Block/Add Site Notification - How to Disable with GPO?
Hello, I haven't been able to find answers anywhere so far to figuring this out. Currently looking into using GPO for disabling the Block/Allow to send site notifications tabs found in Privacy, search, and services -> Site permissions -> All permissions -> Notifications. I have been able to block to turn off notifications for all websites by default and block the "Ask before sending" notification settings in the same menu as mentioned above. I did so by creating a GPO with the following settings: Computer Configuration -> Policies -> Administrative Templates -> Microsoft Edge -> Content Settings After navigating to this folder, I opened the "Default Notification Setting" setting. Inside of it I switched it to Enabled and Don't allow any site to show Desktop notifications. I have already looked at the "Allow notifications on specific sites" and the "Block notifications on specific sites" settings, however these just allow you to add websites that you want to block or allow that the user cannot remove. I have discovered that putting a wildcard "*" into the "Block notifications on specific sites" settings values will not allow the user to add any more sites to the list. However this still leaves the user to add any site they wish to the "Allow notifications from specific sites" setting, which is the main concern considering all sites should have notifications disabled. Has anyone else had this problem and found a solution or workaround? This works in Chrome, but Edge has been difficult Thanks.
Crash when submitting web page input fields with soft keyboard Enter
### Summary Microsoft Edge Canary for Android crashes when submitting web page input fields using the Android soft keyboard Enter key. GitHub search is one stable reproduction case, but this is not GitHub-specific. I have also reproduced similar crashes on other websites with text input/search fields. ### Environment - App: Microsoft Edge Canary for Android - Package: `com.microsoft.emmx.canary` - Version: `152.0.4142.0` - Version code: `414200023` - Device: vivo V2417A - Android SDK: 36 - ABI: arm64-v8a ### Reproduction case 1. Open Microsoft Edge Canary on Android. 2. Navigate to `https://github.com/`. 3. Tap the GitHub search box. 4. Type any text. 5. Press Enter on the Android soft keyboard. ### Expected behavior The input/search action should be submitted normally. ### Actual behavior Edge Canary crashes immediately after pressing Enter. ### Scope This does not appear to be specific to GitHub. The same type of crash can also be triggered on other websites when submitting text input/search fields using the Android soft keyboard Enter key. GitHub is used here as a minimal stable repro because it is easy to test. ### Crash information Exception: ```text java.lang.IndexOutOfBoundsException: Index 24 out of bounds for length 0 ``` Relevant stack trace: ```text java.util.ArrayList.get(ArrayList.java:434) android.view.ViewGroup.getAndVerifyPreorderedView(ViewGroup.java:3873) android.view.ViewGroup.gatherTransparentRegion(ViewGroup.java:7438) android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:5207) android.view.Choreographer.doFrame(...) ``` ### Notes - Reproduced directly on the Android phone. - Trigger appears related to submitting web page input/search fields via the Android soft keyboard Enter key.
FPGA vs ASIC for AI at the Edge: What factors influence your hardware choice?
As AI continues to move closer to edge devices, choosing the right hardware platform has become an important design decision. While both FPGAs and ASICs have their strengths, the best choice often depends on the application's requirements. Here are some of the key factors that engineering teams typically evaluate: Performance and latency requirements Power efficiency Development cost and NRE Time-to-market Production volume Need for future hardware updates FPGAs offer flexibility for rapid prototyping and evolving workloads, making them well-suited for early-stage development. ASICs, on the other hand, can provide significant advantages in performance, power consumption, and cost efficiency for high-volume production. I recently came across a technical article that explains these trade-offs in a structured way and found it useful as a reference: https://www.signoffsemiconductors.com/asic-vs-fpga/ I'd be interested to hear how others approach this decision. Have you migrated a design from FPGA to ASIC? What factors influenced your choice? Are there workloads where you would always choose one over the other?Unlocking the Human Telemetry Layer for Safer Industrial Operations
What if we could track human health & safety conditions as precisely as we do with machines, and take immediate actions to protect our greatest asset, our people? Many industrial organizations still lack visibility into real-time human conditions, even as worker safety and operational risk remain major investment priorities. One of the most important operational signals has largely remained outside the industrial data estate: the human telemetry. VOORMI and Microsoft have joined forces to fill this gap in understanding real human conditions. Through the Mij™ platform, VOORMI brings human telemetry into Azure IoT, enabling enterprises to integrate worker conditions such as heat stress and fatigue into the same operational architecture already used for machines and industrial systems. VOORMI, SWNR’s performance apparel brand, is among the first to bring this technology into garments designed for real industrial field conditions. This integration brings their proprietary wearable technology directly into high-impact worker safety and field operations scenarios. The partnership helps establish a new telemetry layer for industrial operations, allowing human, machine, and environmental signals to converge and drive safer operations, real-time awareness, and adaptive AI workflows. Bringing the Human Signal into Industrial AI with Azure Industrial organizations increasingly recognize that many safety, productivity, and operational challenges occur at the intersection of people and machines. Workers operate in high-heat environments, hazardous conditions, remote sites, and physically demanding field scenarios where situational awareness matters in real time. Historically, worker telemetry has remained fragmented across proprietary wearable platforms and disconnected safety systems, creating governance and operational challenges for enterprise IT and OT teams. Mij™ is designed differently, integrating directly into customer-controlled Azure environments through Azure IoT Operations running at the edge or Azure IoT Hub in the cloud rather than introducing another isolated platform. Running intelligence at the edge enables virtual safety agents and operational workflows to execute closer to the worker, supporting low-latency responses, local interaction with OT systems, and operational resilience even in disconnected or bandwidth-constrained environments. This gives enterprises flexibility to support real-time worker safety responses at the edge while also enabling long-term analytics, reporting, and operational intelligence through Microsoft Fabric. Telemetry from garment-integrated sensors flows through edge gateways into Azure services including Azure IoT Operations, Azure Data Explorer, Azure Managed Grafana, and Microsoft Fabric. The result is a unified operational environment where worker telemetry can live beside machine, site, and environmental data under the customer’s existing identity, security, governance, and analytics model. The vision is simple and transformative: make human telemetry a trusted, first-class industrial data source. Azure Digital Operations as the Intelligence Layer The reference architecture demonstrates how Azure IoT Operations can serve as a scalable operational intelligence layer for worker safety and connected operations scenarios across manufacturing, energy, and field environments. Mij™-enabled garments broadcast Bluetooth Low Energy (BLE) telemetry that can be processed locally through edge gateways and routed into Azure IoT Operations using MQTT and dataflows. Data is then operationalized through Azure Data Explorer and visualized using Azure Managed Grafana dashboards for field operations, worker safety, fleet health, gateway monitoring, and operational readiness scenarios. Telemetry can also be made available to Foundry Local-hosted GenAI agents to support real-time, context aware safety guidance, such as prompting workers operating in high-heat conditions to hydrate or seek cooler environments. While Mij™-enabled garments are the initial implementation, the edge device-to-cloud architecture creates a broader onboarding point for additional wearable, sensor, and field telemetry scenarios over time. This allows enterprises to bring more human and operational signals into a unified Azure-native operational environment. The architecture also supports flexible ingestion patterns for environments where dedicated edge gateways are not practical. Using Microsoft Entra External ID, Azure Container Apps, and Azure IoT Hub, telemetry can securely flow into Azure services without exposing operational infrastructure credentials to client devices. This pattern aligns with the broader Azure adaptive cloud approach: enabling customers to run distributed edge-native services on Arc-enabled Kubernetes infrastructure while maintaining centralized security, governance, and analytics capabilities across the enterprise. Depending on customer architecture preferences, telemetry can be processed through Azure IoT Operations at the edge or ingested directly through Azure IoT Hub for cloud-first analytics and downstream processing in services such as Microsoft Fabric. Edge processing also enables real-time sensor fusion across worker telemetry, ambient environmental conditions, machine parameters, and site-level operational signals, supporting faster safety interventions and more context-aware operational decisions. This gives enterprises flexibility in how they balance edge processing, operational responsiveness, governance and privacy requirements. Enabling the Next Generation of Industrial Workflows The long-term opportunity extends well beyond visualization dashboards. As worker telemetry becomes part of the operational fabric, enterprises can begin building more adaptive and intelligent workflows across worker safety, field readiness, incident response, compliance, environmental monitoring, and industrial AI systems. Human telemetry can provide critical real-time context that complements machine and environmental signals enabling more responsive operations and eventually more autonomous decision-support experiences. By bringing human telemetry into enterprise AI and analytics workflows, organizations can build more adaptive operational systems that improve worker safety, situational awareness, and real-time decision making at scale. This partnership reflects a broader industry shift: industrial transformation is no longer only about connected machines. It is about connected operations where people, equipment, environments, and AI systems participate in a shared operational intelligence layer. With SWNR’s Mij™platform and Azure IoT Operations, Microsoft and VOORMI are helping unlock that future. Learn more: Mij™ product page: https://swnrtechnologies.com/pages/mij Learn more about Azure IoT Operations: Documentation & Getting Started See what’s new with Azure IoT Hub: Preview Documentation To get started with a pilot, contact: pilots@swnrtechnologies.com
Smaller updates, faster downloads with delta updates in Azure Device Update for IoT Hub
Keeping IoT fleets secure and up to date shouldn't mean shipping the full software image to every device, every time. With delta updates in Azure Device Update for IoT Hub, fleet operators can send only what has changed between versions, reducing download size, bandwidth use, and download time on most networks. In our demo below, an incremental change produced a delta ~97% smaller than the full image — a glimpse of what's possible for small, incremental changes. The timing matters. Security patch cadence keeps rising as Common Vulnerabilities and Exposures (CVEs) accumulate, more fleets (like smart meters and remote agricultural sensors) are running over metered networks such as cellular and satellite, and deployments are crossing scales where every megabyte per device adds up. At that point, full-image rollouts stop being a minor inefficiency and become a real cost and reliability problem. As part of a broader Azure IoT investment in more efficient edge-to-cloud data delivery, the new Device Update reference implementation agent 1.3.0 provides delta updates as a starting point that customers can build, validate, and integrate into their own environments. In this post, we'll walk through what delta updates are, how they work, and what else is new in 1.3.0 — including expanded Linux platform support to build on Debian 13 and Ubuntu 24.04, and new device-side visibility for tighter update control and coordination with device operations. Improving over-the-air (OTA) efficiency with delta updates When deploying OTA updates across a fleet, update size directly affects how quickly and efficiently updates move through the system. Traditional full image updates require every device to download the entire software image, even when only a small portion has changed. As deployments scale, this increases bandwidth usage and delivery overhead. Delta updates take a more efficient approach. Rather than transferring a full image each time, devices download a smaller delta artifact and reconstruct the target version locally, reducing the amount of data transferred across the fleet. By sending only what's changed between versions, delta updates improve efficiency in three ways: Less data on the network. Smaller payloads consume less bandwidth per device, and the savings multiply across large fleets. Faster downloads. Smaller artifacts reduce the time each device spends downloading the update, especially on variable or constrained networks. Lower delivery overhead at scale. With less data per rollout, teams can deliver updates more flexibly across large fleets, reducing the need to stagger deployments for bandwidth caps or capacity windows. This approach works particularly well for frequent, incremental changes such as bug fixes or small feature updates. For larger updates where most of the image has changed, or on devices with limited processing capacity, using a full image update may be more practical. How delta updates work Delta updates fit into the same Device Update deployment model you already use for full image updates. What changes is how update content is delivered and applied on the device. When you import an update into Device Update, you include both the full target update and one or more delta artifacts as part of the same update. When that update is deployed, the Device Update agent on each device picks the right path: If a compatible delta is available, the device downloads the delta, reconstructs the full target update locally, and installs it through the standard update workflow. If no compatible delta is available, the device falls back to downloading and installing the full target update. For details on integrating delta updates into your update workflow, see Deploy delta updates to devices. It guides you through generating delta artifacts on your build machine using the DiffGen reference tool, or as part of your image build process, and setting up the right components on the device to apply them. See the impact: Delta updates in action The following demo shows what a typical incremental change looks like with delta updates: a single-file change between image versions produces a 7 MB delta against a 240 MB full image — roughly a 97% reduction in data transferred for that scenario. Across 10,000 devices, that’s about ~2.3 TB less data crossing your network in a single rollout. Savings may vary depending on how much the versions have changed and how quickly the device can rebuild the full image locally, but they compound quickly at fleet scale. For example, a utility company patching firmware across hundreds of thousands of cellular-connected smart meters, or an agricultural operator updating remote field sensors over satellite links, sees carrier data costs drop significantly during each rollout. To bring this to life, the demo below shows what’s possible with delta updates — generating, deploying, and applying them on a Raspberry Pi device using Device Update for IoT Hub. Beyond delta updates: What’s new in the 1.3.0 reference implementation The 1.3.0 reference implementation also includes improvements that strengthen device-side coordination and expand Linux platform support. Coordinate updates with device workloads On many devices, updates run while the device is doing other work, such as handling sensor data, running a local UI, or managing background tasks. Without visibility into update status, device software can trigger conflicting operations or let battery-powered devices enter sleep mid-update. The 1.3.0 reference implementation helps your device software work alongside the update process rather than against it — coordinating with active updates, keeping devices awake through long downloads, and surfacing update status to local applications. A new device-local agent status API makes this possible: applications on the device can see what the Device Update agent is doing at any time, for example, whether an update is in progress. With that visibility you can: Avoid triggering operations that would conflict with an active update Keep battery-powered or low-power devices awake while an update is downloading or installing Surface update status in local applications or user interfaces Diagnose update behavior using local signals. Because the API runs locally, it works even when network connectivity is limited or intermittent. The payoff is fewer disrupted rollouts, more reliable updates across your fleet, and easier troubleshooting when something needs attention. Expanded Linux platform support The 1.3.0 reference implementation now adds Debian 13 and Ubuntu 24.04 to the Linux distributions you can already build on, including Debian 12 and Ubuntu 22.04. That gives you flexibility to work on newer OS versions without changing your existing update workflow. Call to action Ready to see the benefits? Extending and adapting the 1.3.0 reference implementation is a device-side change — existing service-side deployments and configurations stay as they are, so you can move at your own pace. Build from the Device Update for IoT Hub GitHub repository, integrate delta artifact generation into your build pipeline, and run your first delta in your next rollout to measure the bandwidth and download savings across your fleet. Learn more: Device Update for IoT Hub documentation | Microsoft Learn Deploy delta updates with Azure Device Update for IoT Hub | Microsoft Learn We’d love your feedback. Help shape the future of Azure Device Update for IoT Hub at aka.ms/dufeedback.
