Access VBA performance dramatically slowed since June Update
We are running an access based application with a large vba project. One customer with four different instances of this project experience extreme slow down in performance on all instances during the last week. We made no changes. The Microsoft Office Update was applied automatically. We believe the problem happened then. We have tried reverting to several different previous versions of Office but symptoms still remain.Bug fixes in Microsoft Access - Current Channel Version 2605 (Build 16.0.20026.20118)
Bug Name Issue Fixed Edge Browser Control didn't render PDFs on some machines When the Edge Browser Control was used to display a PDF, on some machines the PDF would not render at all if the registry value "HKEY_CLASSES_ROOT\.pdf\Content Type" was missing. Access now provides the missing content type, so the Edge Browser Control can render the PDF. Export to SharePoint failed for tables with both lookup fields and attachment columns When exporting an Access table to a SharePoint list, if the table contained both a lookup field and an attachment column, the export could fail with an error. The export now handles this combination correctly, so the export completes successfully. Conditional Formatting color picker showed a reduced palette in Version 2604 A regression introduced in Version 2604 caused the Conditional Formatting color picker to display a smaller set of color choices than previous versions. The full legacy color palette has been restored. Some Unicode characters displayed incorrectly in objects exported to Excel When exporting an Access object whose name contained certain extended Unicode characters, the resulting file's sheet name displayed the characters incorrectly. These characters are now preserved correctly during export. Power BI Gateway couldn't refresh semantic models from .accdb files Refreshing a Power BI semantic model that connected to a .accdb file via the on-premises gateway could fail with "Unspecified error". Connection setup has been adjusted so the gateway can successfully refresh the model. Monaco SQL view: Ctrl+Z didn't undo Ctrl+Shift+K line deletion In the new Monaco-based SQL editor, pressing Ctrl+Shift+K to delete the current line removed the line, but a subsequent Ctrl+Z would not restore it. Undo now works correctly for this and similar editing operations. Document tab text didn't scale with Windows text-size setting When the Windows display setting for text size was increased, document tab labels and the record navigation bar continued to render at the standard size, while other Access UI scaled correctly. The document tabs and record navigation bar now honor the system text-size setting. Error when editing a Long Text field after a write conflict When a write conflict occurred on a record containing a Long Text field, subsequent attempts to edit the field could fail with an error. The data path now refreshes the cached field values correctly after a conflict so that further edits succeed. Access terminated unexpectedly when reading Edge Browser Control properties in form design view In form design view, retrieving the ReadyState or LocationUrl property on an Edge Browser Control could cause Access to terminate unexpectedly. Both properties now return safely in design view. "Copy" prefix was prepended instead of appended to copied object names When duplicating a database object, Access named the copy "Copy of Form1" instead of "Form1 - Copy". This made copies of related objects sort apart from their originals in the Navigation Pane. Copy-of names now append the suffix, so related objects stay together when sorted alphabetically.Enhancing Data Security and Digital Trust in the Cloud using Azure Services.
Enhancing Data Security and Digital Trust in the Cloud by Implementing Client-Side Encryption (CSE) using Azure Apps, Azure Storage and Azure Key Vault. Think of Client-Side Encryption (CSE) as a strategy that has proven to be most effective in augmenting data security and modern precursor to traditional approaches. CSE can provide superior protection for your data, particularly if an authentication and authorization account is compromised.We Gave Ourselves 20 Minutes to Build an AI Agent for a Lumber Company. The Timer's Still on Screen.
Here's a confession: most "build with AI" webinars are 60 minutes of slides, 5 minutes of a polished demo someone rehearsed for a week, and a closing CTA. You leave inspired but not really sure what you saw. So we tried something different. We put a visible countdown timer on the screen and gave ourselves 20 minutes to do two things, live: Build an AI agent that solves a real business problem Deploy a working AI application to Azure No edits to hide the awkward parts. No "and here's one I prepared earlier." Just the timer, the screen, and a working app at the end. The on-demand recording is up now. Here's what's in it and why you should carve out 20 minutes for it this week. The setup: why lumber? 🏘️ We needed a real business problem, not a toy one. So for the demo, we role-play as the owner of Contoso Lumber — a regional lumber business with a very specific, very real headache: Should we sell our inventory now, or hold it longer? Sell too early, miss a better price. Hold too long, eat storage costs. Lumber prices fluctuate with global competition, macro shifts, even the weather. In the past, decisions like this came from morning meetings and gut instinct, or maybe the occasional ad-hoc spreadsheet that nobody could reuse a month later. It's the kind of decision that should have an analyst behind it — except most growing businesses can't afford to hire one full-time. So we build the AI agent that does. (Yes, lumber. We know. Stick with us — the boring industry is exactly the point. If it works here, it works for your business too.) What we actually build (in 20 minutes flat) The webinar walks through the entire flow, end to end: Part 1 — The agent. We open Microsoft Foundry at ai.azure.com, browse the model leaderboard (there are over 11,000 models to choose from — we compare a few on the cost-vs-quality chart), pick one, write a plain-English instruction for the agent, upload a CSV of historical lumber pricing, and ask it a real question: "If I cannot sell one of my products today unless I offer my clients a 35% discount, and knowing the historical pricing data, should I still sell it?" The agent runs a break-even analysis and comes back with a reasoned recommendation — hold for 3–6 months, here's the math on why, here's where storage costs start eating the upside. Then we add voice mode (now you can ask the agent for pricing recs from a coffee shop on your phone), and lock down guardrails to block jailbreaks, prompt injection, data leakage, and — because we're feeling fancy — profanity in responses. Part 2 — The app. With the agent done, we pivot to deploying a full AI chat application to Azure. From scratch. Using exactly five commands in Azure Cloud Shell: azd auth login git clone <repo> cd <folder> azd up azd down # (this one's for when you're done — kills everything to avoid surprise bills) That's it. The template handles the Container Apps setup, the architecture-aligned-to-Well-Architected-Framework stuff, all the boilerplate that usually eats half a sprint. By the end of the segment, there's a working AI chatbot running on a real Azure URL. We even pause the timer when we're just explaining things, so you know the 20-minute clock is honest about build time, not talk time. Why this format is more useful than another slide deck A few things this webinar shows that a written tutorial can't: The Foundry UI is super navigable. You watch someone do it. You see where the buttons are. You see what the leaderboard looks like when you're comparing GPT-5.3 Codex against Kimi K2.5 on a cost-to-quality chart. (Spoiler: Kimi wins this particular trio. Your mileage will vary depending on your workload.) The "no-stitching" claim is real. Models, data, agents, guardrails, deployment — all in one place. You don't need to leave Foundry to wire seven products together. The webinar makes that concrete by showing you the actual flow without cutting. Five commands really is five commands. This is the part people are most skeptical about until they see it. azd up does the work. The infrastructure provisioning, the container app, the AI service hookup — all of it. You can delete it just as fast. azd down tears everything back down. Useful when you're experimenting and don't want a $40 surprise on your Azure bill next month. What's on screen at the end By the 20-minute mark: A published AI agent named for the lumber business, with guardrails, voice mode enabled, ready to be called from Teams, Microsoft 365 Copilot, or any application via endpoint A separate AI chat application deployed to Azure Container Apps, with a live URL Logs, observability, the full Foundry control plane — all available out of the box And in the closing minutes, four very concrete next steps for what you do next if this sparked an idea for your own business — including Azure Accelerate (if you want Microsoft experts in the room with you), the partner network, and the Microsoft marketplace if you'd rather buy than build. Watch the recording The on-demand recording is available now. Block 20 minutes — that's literally all it takes — and ideally watch with your Azure portal open in another tab so you can follow along. If you're the kind of person who learns by doing, pause at the agent-building section and try it yourself in parallel. Foundry is free to explore; the agent we build in the webinar costs cents to run. → Watch the on-demand webinar A few things we'd love feedback on If you watch it, we'd genuinely love to know: Did the timer help or distract? (We thought it would feel gimmicky. It turned out to be the most-mentioned thing in early feedback.) What use case from your business would you want to see in the next one? We're picking the next demo problem from comments. Was the lumber thing weirdly compelling or were you just here for the Azure parts? Drop a comment, tag us, or grab a partner and try building your own version this week. The timer's reset. Your 20 minutes start whenever you press play. Want to go deeper than the webinar? Two companion reads: From Idea to Impact: How Growing Businesses Scale with Azure (five real customer stories with the full architectures) and AI Made Simple: 3 Practical Moves for Growing Businesses (the structured playbook for figuring out what to build first).Extend Microsoft Purview data protection to AWS Bedrock agents for cross-cloud AI governance
Organizations are moving fast with AI, and many of those AI workloads are not staying in one cloud. A team might use Microsoft 365 and Microsoft Purview for governance and in addition to Microsoft Foundry they may still choose to run an AI agent on AWS Bedrock or on the Google Cloud Platform. The technical challenge is straightforward: how do you keep one consistent set of data security, governance, and compliance controls when the agent itself runs outside Microsoft Azure? This is where Microsoft Purview becomes the central policy engine for your data estate. In this post, we show why that matters and then walk through a practical example: an expense approval agent running on Amazon Bedrock, protected by Microsoft Purview Data Loss Prevention (DLP) policies. ExpenseApprovalAgent" details of the Agent blade Why Purview should be the central policy engine Most organizations do not want separate policy stacks for every cloud, every model endpoint, and every app team. That leads to duplicated controls, inconsistent enforcement, and audit gaps. The better model is to separate where workloads run from where policy decisions are made. That is the value proposition for Microsoft Purview in cross-cloud AI scenarios. Purview gives you: A consistent policy layer for sensitive information types such as credit card numbers, Social Security numbers, financial data, and other regulated content. A governance plane that can extend beyond Microsoft-hosted workloads into multi-cloud environments. A compliance framework with auditability, policy traceability, and a familiar operational model for security and compliance teams. A way to apply data-aware controls to AI interactions, not just to storage locations. In practical terms, that means the same organization that already trusts Purview to govern Exchange, SharePoint, Teams, and Copilot can use Purview to govern prompts and responses in a Bedrock-based agent as well. The key architectural shift is this: your app does not need to invent its own data policy engine. It can call Purview at the points where risk exists. What this Bedrock agent demonstrates The sample solution in this blog is a cross-cloud AI pattern: The frontend is a single-page browser-based chat app. Users authenticate with Microsoft Entra ID via MSAL. The backend runs in AWS Lambda. The model is Amazon Bedrock using Nova 2 Lite. Microsoft Purview evaluates prompts and model responses for DLP policy violations. This matters because it proves a broader point: Microsoft Purview can govern AI interactions even when the model and compute are not running in Azure. The core architecture As shown above the end-to-end flow follows this pattern: A user signs in through Microsoft Entra ID from the frontend. The frontend sends the user's access token and prompt to an API endpoint in AWS. The Lambda function exchanges that token using the On-Behalf-Of flow so Purview can evaluate under the signed-in user's identity. Purview scans the full prompt for sensitive information before the model is called. If the prompt is allowed, the Lambda function sends the request to Amazon Bedrock. Purview scans the model response before it is returned to the user. The frontend shows the result along with a Purview evaluation badge. That gives you two strong governance controls: In-line data loss prevention enforcement, which can block risky requests before they ever reach the model. Response-time enforcement, which can stop sensitive data from being returned even if a model generates it. The implementation also uses the user's identity for policy evaluation. That is important because governance decisions should reflect who is asking, not just what application is running. Why this pattern is useful for security, governance, and compliance teams There are three reasons this pattern is worth paying attention to. First, it aligns policy with risk rather than with hosting location. The compute might run in Lambda and the model might be in Bedrock, but Purview still remains the policy decision point. Second, it improves operational clarity. Security teams do not have to learn a different governance toolchain for each AI stack. They can keep using Purview concepts, policy models, and audit workflows. Third, it supports real-world adoption. Most large enterprises are hybrid and multi-cloud already. A governance pattern that only works for one vendor's runtime is not enough. Policy definition in Purview Two polices are needed to enforce DLP-a collection policy for Enterprise AI Apps and a DLP policy Collection policy 2. DLP policy Follow the steps outlined here to create the DLP policy for Enterprise AI Apps. Sample provided: purview-api-samples/DLPforCustomAIApps at main · microsoft/purview-api-samples To replicate this scenario, follow this link to the official GitHub repo: purview-api-samples/AWSBedrock at main · microsoft/purview-api-samples Once deployed, you will have: An AWS Lambda function that calls Amazon Bedrock. A browser frontend that authenticates with Microsoft Entra ID. Microsoft Purview evaluating both prompts and responses. A demo flow where safe prompts succeed and sensitive prompts are blocked. With the App and agent deployed, now comes the moment when the architectural value becomes clear. The model runtime is AWS Bedrock, but the policy decision is still coming from Microsoft Purview. Below screenshot shows the prompt containing sensitive information being blocked based on the policy evaluation by Purview. Minimal code integration requirements using the SDK Below is the code needed to perform the integration between Purview and Bedrock to perform the in and outbound inspection of content destined to and from the Bedrock model. Results of Purview’s verdict presented to user in the App UI Review governance evidence in Purview Data Security Posture Management Summary The bigger story here is not just that Microsoft Purview can protect an Amazon Bedrock agent. It is that organizations can centralize data security, governance, and compliance policy even while their AI architecture becomes more distributed across multiple clouds. That is the operational win. Developers keep the freedom to choose the best runtime and model platform. Security and compliance teams keep a central policy engine they already understand and trust. AI applications can be multi-cloud, but your data protection model does not have to be fragmented. Additional resources Configure Microsoft Purview - purview-sdk | Microsoft Learn Microsoft Purview Developer Platform Documentation - purview-sdk | Microsoft Learn
From AI Suggestions to Autonomous CRM Actions in Dynamics 365
Modern CRM AI solutions often stop at case summarization—but real transformation requires more. This blog introduces a CRM Copilot Agent Accelerator built on Microsoft Power Platform, designed to evolve AI from simple insights to predictive intelligence and ultimately to autonomous actions. By combining Dynamics 365, Dataverse, Power Automate, and AI Builder, and extending capabilities through modular add-on packs, this approach enables organizations to reduce manual effort, improve decision-making, and scale service operations efficiently—without additional Copilot licensing.
'New Teams' - DOES NOT Remember Window Positions
Can anyone tell me if there is a FIX for this??? Ever since I upgraded to the NEW and IMPROVED [and I choke on those words] Teams, DOES NOT remember my previous window positions for either the main window or individual chats. The Classic Teams did this. When can we expect this be FIXED? This is HIGHLY annoying. It is bad enough that Microsoft feels the need to have this fill nearly your entire screen [as if it was the only application you used]. The very least you could do is check these sorts of issues before the app went to production and in my opinion this app is nowhere near production worthy. Please FIX this immediately or provide a workaround that can be utilized as soon as possible. I wish I could use the old 'classic' Teams, but it will no longer let me. At least it would remember my previous Window Positions.Zoom in or out of forms, tables, and queries when in Form View or Datasheet View
Access now lets you zoom in and out when you’re working with forms, tables, and queries in Form View or Datasheet View. Zoom in for a closer look at your data or zoom out to see more on screen at once. You can adjust the zoom level using the Zoom button on the ribbon, the zoom slider on the status bar, or keyboard shortcuts. Zoom is also available in Print Preview for reports. Zoom isn’t supported in Report View or Design View. This feature is available in Access for Microsoft 365, version 2605 and later. Choose a magnification setting from the ribbon On the Home tab, select Zoom and choose one of the following options: 50%, 75%, 125%, 150%, 175%, 200%, or 500%. To return the view to 100% zoom, click Zoom 100%. If you prefer to use the keyboard, you can press Ctrl + Alt + 0 (zero). Use the zoom slider to quickly zoom in or out On the status bar in the lower right-hand corner of Access, select the zoom slider. Slide to the percentage zoom setting that you want. Press – or + to zoom in gradual increments. Use zoom keyboard shortcuts or mousewheel To zoom in, press Ctrl + Alt + Plus (+). To zoom out, press Ctrl + Alt + Minus (-). To return to 100% magnification, press Ctrl + Alt + 0 (zero). To use the mousewheel and scroll to zoom in or out, press Ctrl + mousewheel. Change your default zoom percentage Access doesn't save zoom settings on closing and reopening a form. Instead, it opens your form using the default zoom setting. To set your zoom default percentage, choose File > Options > Current Database > Application Options and choose the Default Zoom setting. Note Content inside of ActiveX controls, such as the text in a TreeView control, doesn't resize when zoomed. Zooming in Access only affects Access-native controls. If a form uses ActiveX controls, consider replacing them with native Access controls so they scale with the rest of the form.Discover new Microsoft Marketplace innovations announced at Microsoft Build
At Microsoft Build, Microsoft shared new opportunities for software development companies and partners to build, scale, and monetize AI apps and agents through Microsoft Marketplace. Explore how Microsoft Marketplace is helping software companies accelerate go-to-market strategies, expand customer reach, simplify procurement, and unlock new revenue opportunities across the Microsoft ecosystem. Learn how organizations can take advantage of Azure and Marketplace capabilities to support AI innovation and deliver enterprise-ready solutions faster. Whether you’re building intelligent applications, growing your commercial marketplace presence, or exploring new ways to monetize AI-powered solutions, this is a valuable resource for understanding the latest Microsoft Marketplace announcements and opportunities coming out of Build. 👉 Read more: Build, scale, and monetize apps and agents with Microsoft MarketplaceMake any agent enterprise-ready with the Agent 365 SDK
One of the biggest barriers to enterprise adoption is the lack of centralized controls. Before deploying an agent broadly, organizations need clear answers: What is this agent allowed to do? What data can it access? How is it monitored? And how do we step in when something goes wrong? Today, developers often piece together identity, runtime protection, and observability using a mix of point solutions and open-source tools. The result is fragmented policy management, disconnected monitoring, and operational overhead that’s difficult to scale within existing IT and security systems. What enterprises need instead is a unified control plane that brings these capabilities together. Introducing the Agent 365 SDK On May 1, Microsoft announced the general availability of Agent 365, the control plane for enterprises to observe, govern, and secure agents at scale. Agents built on the Microsoft AI platform (Agent Builder, Copilot Studio, and Microsoft Foundry) get Agent 365 capabilities automatically, with zero additional developer effort. For agents built on external platforms or open-source frameworks, the Agent 365 SDK provides the path in. The SDK enables enterprise-grade observability, governance, and security, while the Agent 365 CLI provisions the agent identity and registers the agent in Agent 365 from day one. For example, a back-office agent built on Microsoft Foundry and a customer-facing agent built with the OpenAI Agents SDK can both be managed through Agent 365, using the same identity model, observability signals, and policy engine, no matter which platform or framework on which the agent runs. What you get with the Agent 365 SDK Observability A unified agent registry. Every agent registered through the SDK appears in a unified Agent 365 registry, giving admins visibility into ownership, usage, connected tools and knowledge sources, and assigned permissions. Additional signals also help surface unmanaged local agents in the same control plane. Security Operations Center (SOC) visibility in Microsoft Defender. Security Operations Center teams can use Microsoft Defender telemetry to hunt across agent activity, identify vulnerabilities, and investigate potential risks across the entire agent fleet Governance Agent lifecycle management. Apply rules-based policies to automatically expire inactive agents, flag ownerless agents, and block risky ones. Onboarding and agent governance. Deploy agents to specific users or groups only after permissions, policies, and reviews are complete. Block, unblock, or remove agents on demand to control availability. Policy templates. Group existing policies from Entra, Purview, Defender, and SharePoint into reusable templates that apply automatically during agent approval or onboarding. Tool controls for agents. View, allow, or block tools across the tenant so agents only use approved tools, enforcing consistent governance without per-agent configuration. Security Agent identity in Entra. The SDK generates an agent identity in Entra so the agent can be managed, and policies and role assignments can be applied to it the same way they are applied to users. Learn more in our Entra Agent ID developer blog post. Access control. Agents can be secured by Entra Conditional Access and Identity Protection for runtime protections as agent behavior evolves. Threat detection in Defender. Agent activity surfaces in Microsoft Defender alongside the rest of the estate, with alerts wired into the same incident pipeline the SOC already runs on. Threat blocking tool invocation. When you register tools with Agent 365, calls to and responses from those tools are protected by Defender’s runtime protection, blocking high-risk tool calls and actions before they execute. How companies are putting it to work Many software companies have already integrated the Agent 365 SDK into the agents they build, spanning three primary categories. The first is AI-native software vendors building customer-facing agents, such as Genspark, Zensai, Egnyte, and Zendesk. The second includes agent platforms and “agent factories” where customers build and run their own agents, including Kore.ai, Kasisto, and n8n. And the third is enterprises developing custom internal agents for their own employees and business processes. All three groups integrate with the Agent 365 SDK for the same reason: when these agents are deployed into an enterprise, organizations can immediately observe, govern, and secure them in Agent 365 with no additional work required for the core capabilities. More advanced scenarios such as data security and compliance can then be added through Microsoft Purview APIs when required. Two examples of what this looks like in practice Kore.ai is an enterprise platform for building and managing AI agents and assistants. Raj Koneru the CEO of Kore.ai had this to say about Agent 365: "Enterprises can easily build AI agents today but scaling them with trust and governance is where most initiatives stall. With Kore.ai deeply integrated into Microsoft Agent 365, identity, security, and governance are built in from the start, empowering enterprises to move from pilots to AI at scale with confidence." — Raj Koneru, Chief Executive Officer, Kore.ai Zensai is an AI-native software development company that ships its Human Success Agent to enterprise customers. Emma Taylor, Culture & Organizational Development Manager at Phoenix Software Solutions, one of Zensai’s customers, on what Agent 365 makes possible: "Zensai has given us a clear view of how our people and programs are performing, helping us track the metrics that matter. The depth of reporting across the Human Success Platform has been a game changer for our team. We're particularly excited about the Human Success Agent, with Agent 365 delivering the governance and observability our administrators need to confidently manage AI in the enterprise responsibly while surfacing the data and insights that drive better decisions across our business." — Emma Taylor, Culture & Organizational Development Manager, Phoenix Software Solutions The takeaway is direct: integrate once with Agent 365 SDK, and every customer who deploys your agent can easily enable enterprise-grade controls. Get started today The Agent 365 SDK is available now. If your agent is already running, you can onboard it in three steps. Install the SDK in your agent project using Python, TypeScript, or .NET. Register the agent with the Agent 365 CLI to provision its identity and automatically onboard it into Agent 365. Wrap your agent entry point with the SDK to stream activity and telemetry into the Agent 365 control plane. For data security visibility and controls, you can integrate Microsoft Purview APIs to enable capabilities such as prompt-based Data Loss Prevention (DLP), Data Security Posture Management, Insider Risk Management, and core compliance features including eDiscovery, Communication Compliance, Audit, and Data Lifecycle Management. Learn more in our Purview developer blog post. Get started with Agent 365 development Keep learning Microsoft is actively shaping the Agent 365 SDK based on what builders are asking for. A few places to go deeper and see the SDK in action: Watch OD840: The Microsoft Build on demand developer session that goes deeper on Agent 365 SDK and the design decisions behind it. Watch BRK251: Build secure and enterprise-ready agents with Agent 365. A hands-on breakout that walks through how Agent 365 SDK and Microsoft Purview APIs work together across the agent lifecycle, with practical examples for runtime visibility, identity-aware access, data protection, and policy-based governance. Available on Wed, Jun 3 11:30 AM - 12:15 PM PDT and on demand. Browse the docs: For quick-starts, reference, and the layered toolkit guide. Go deeper on Purview for agents: Start with the Purview developer blog for the story, then the Microsoft Purview developer documentation for the full reference. Read more on Entra Agent ID: Start with the Entra Agent ID developer blog, then the Microsoft Entra Agent ID documentation for the full reference. Shipping an agent that IT and security teams can actually approve doesn't have to mean piecing together multiple solutions. With the Agent 365 SDK, you can build enterprise-ready agents that organizations can deploy with confidence. Co-Authored by Jeremiah Follis
