The post Microsoft and AWS simplify cloud connections for the AI era appeared first on Source.

How does MSIX service a package while it’s in use?

Simple: It doesn’t.

A core principle of MSIX servicing is:

Do not service a package while it’s in use.

Deployment provides several ways to deal with that constraint. Options range from terminating applications to deferring servicing until the package is no longer in use.

How hard can it be?

‘Servicing a package’ means any deployment activity modifying software, including update, remove, repair and other operations.

Altering installed software can be highly disruptive if the software is in use. Executables and DLLs may be mapped into running processes. File and registry writes may be in progress. Processes may be connected through COM, named pipes, or other IPC mechanisms.

There are ways to handle it, but how is unique to each application. There’s no generally applicable solution for all applications. Other than “Don’t do that”.

How hard can it be? Hard enough for any single app. Across the spectrum of apps on Windows? Very.

One size can’t fit all, so MSIX offers several options.

Default Behavior: Fail with ERROR_PACKAGES_IN_USE

In the simplest case, Deployment rejects a request to service a package while in use. For example, assume Contoso.PointOfSale-v1.msix declares an application using Contoso.PointOfSale.exe. The application is running. A deployment request to update the package to v2 will detect the Contoso.PointOfSale.exe process is using the v1 package and fail the request e.g.

Add-AppxPackage 'C:\Packages\Downloads\Contoso.PointOfSale-v2.msix'
...
Add-AppxPackage : Deployment failed with HRESULT: 0x80073D02, The package could not be installed because resources it modifies are currently in use.
...

Deployment returns ERROR_PACKAGES_IN_USE (0x80073D02), indicating the deployment operation cannot proceed because it would service a package while in use.

Option 1: Shut Down the Application

One option is to quit the app using the v1 package to unblock the update.

Another option is to terminate the app via TerminateProcess(), TASKKILL, PowerShell cmdlets or similar utilities.

PackageManager provides an option to do exactly this: ForceTargetAppShutdown.

var packageUri = new Uri("C:\\Packages\\Contoso.PointOfSale-v2.msix");
var options = new AddPackageOptions();
options.ForceTargetAppShutdown = true;
var packageManager = new PackageManager();
var result = await packageManager.AddPackageByUriAsync(packageUri, options);

Or use the similarly named -ForceTargetApplicationShutdown option with the Add-AppxPackage PowerShell cmdlet:

Add-AppxPackage 'C:\Packages\Contoso.PointOfSale-v2.msix' -ForceTargetApplicationShutdown

This deployment request checks for processes using the target package. It shuts them down, forcibly if necessary, to unblock the deployment operation.¹

Option 2: Defer the Update

Failure and TerminateProcess() are rather stark options. Not every process can quit or be terminated harmlessly. For example, it would be disruptive if Terminal is running a batch job that takes hours to complete.

MSIX offers an opt-in solution in AppxManifest.xml: defer</>.

When a package sets uap17:UpdateWhileInUse² to defer, Windows defers the update rather than shutting down the application. This also takes precedence over force-update options such as ForceTargetAppShutdown: Windows ignores those options for a package that declares deferred update behavior. Windows defers the update until the package is no longer in use. Deployment completes it at the next opportunity.

Alternatively, deferred registration can be requested at runtime for an individual deployment operation via DeferRegistrationWhenPackagesAreInUse. If a package is currently in use, registration is delayed and completed when the package can be updated, such as on the application’s next activation.

For example, using the PackageManager API:

var packageUri = new Uri("C:\\Packages\\Contoso.PointOfSale-v2.msix");
var options = new AddPackageOptions();
options.DeferRegistrationWhenPackagesAreInUse = true;
var packageManager = new PackageManager();
var result = await packageManager.AddPackageByUriAsync(packageUri, options);

or the Add-AppxPackage PowerShell cmdlet:

Add-AppxPackage 'C:\Packages\Contoso.PointOfSale-v2.msix' -DeferRegistrationWhenPackagesAreInUse

Many apps, packaged and unpackaged, offer this sort of update experience. When an update is available, the app offers an ‘Update now’ option: “Hey buddy, I’ve got an update. If you want it now, great. If not, I’ll take care of it later when you’re not using me.”

This gives developers two ways to request deferred updates: a package can opt in to the behavior through its manifest, or an individual deployment request can opt in through an API or tool.

Detect a Deferred Update

Can you detect if a package has an update deferred?

Yes!

PackageDeploymentManager.IsPackageRegistrationPending returns true if the package family has a pending (previously deferred) update for the current user.

PackageDeploymentManager.IsPackageRegistrationPendingForUser returns true if the package family has a pending (previously deferred) update for the specified user. As usual, admin privilege is required if the specified user isn’t the caller.

Defer Removal While In Use

Remove operations implicitly have ‘Force’ semantics so they have no explicit [ForceTargetApplicationShutdown] option.

But what if an application is busy?

MSIX offers similar deferred behavior for removal via PackageManager.RemovePackageAsync(packageFullName, RemovalOptions.DeferRemovalWhenPackagesAreInUse):

var packageManager = new PackageManager();
string packageFullName = "Contoso.PointOfSale_2.3.4.5_arm64__1234567890abc";
var options = RemovalOptions.DeferRemovalWhenPackagesAreInUse;
var result = await packageManager.RemovePackageAsync(packageFullName, options);

If the package is in use, Deployment marks it for removal at the next opportunity³ instead of terminating processes to unblock the removal. The algorithm is effectively:

IF package is in use
    IF options.DeferRemovalWhenPackagesAreInUse is set
        Mark the package for deferred removal
        return SUCCESS
    ELSE
        Ask app to shutdown
        IF app still running
            TerminateProcess()
        ENDIF
        IF app still running
            return ERROR_PACKAGES_IN_USE
        ENDIF
    ENDIF
ENDIF

// package is not in use
Remove the package
return SUCCESS

¹ Processes are requested to shut down and, if necessary, may be forcibly terminated via TerminateProcess().

² uap17:UpdateWhileInUse requires Windows 11 version 24H2 (build 26100) or later.

³ Deployment completes a deferred removal when it gets an opportunity after the package is no longer in use. Depending on how the package is used, that may not occur until a later user session.

The post Servicing While In Use and ERROR_PACKAGES_IN_USE appeared first on Inside MSIX.

Executive Summary, Day One
📁 Inbox 5:05AM
To: Ternus, John <jternus@apple.com>
Reply-to: CEO-transition-team@apple.com

Welcome to your first day as CEO! Hopefully you're finding your new office spacious and comfortable. If you have trouble with any of the doors just ping us - being a Jony Ive design, you won't find anything as unsightly as a door handle here!

Today's memo includes a summary of the business, broken out by division. The day's schedule is also attached; please note that the Apple Intelligence team needed to delay the new Siri discussion until a later date, but they promise they're "for real" this time.

Hardware
Everything …

Read the full story at The Verge.

Today, Microsoft published its 2026 Responsible AI Transparency Report. The report highlights the progress we’ve made in building and deploying AI responsibly, supporting our customers, and strengthening our responsible AI governance, tools, and practices. You can explore the report in its entirety here.

AI is moving fast, and so are societal expectations. The boundaries of what people can accomplish with AI are expanding, and communities are asking more questions about how AI systems are designed, built, and used. As AI becomes more integral to how we live and work, confidence that AI systems are operating reliably and securely is becoming an essential prerequisite to their broad and beneficial adoption.

At Microsoft, we have been building a responsible AI program for nearly a decade, rooted in two core beliefs: that trust is foundational to realizing the benefits of AI and that the empowerment of people and organizations must remain at the center of our strategy. As capabilities advance and adoption accelerates, that experience is helping us meet this moment and adapt for what comes next.

Our third annual Responsible AI Transparency Report shares how our program is evolving and the priorities that continue to shape our work. Over the last year, investing in three specific areas has enabled us to embed trust more deeply and at greater scale: adaptive governance and technical risk management, practical tools and capabilities, and shared practices and strong partnerships. These investments cut across five trends shaping the AI landscape, including the rapid expansion of agentic AI.

Taken together, these trends and investments underscore our view that model capability alone will not determine the impact of AI. That will depend on organizations that develop and deploy AI technologies that deliver real value—and govern them with the rigor and adaptability needed to earn and sustain trust.

Adaptive governance and technical risk management

As the frontiers of AI advance, we are making our governance more adaptive and more tightly integrated with engineering workflows. In practice, this means that we have updated our policies to better match the AI tech stack and AI value chain, evolved our risk management practices to address emerging AI capabilities and risks, and strengthened the readiness of our responsible AI community: the people who operationalize our program at enterprise scale.

This year, we re-engineered our Responsible AI Standard to make it more adaptive to evolving technical realities, uses, risks, and regulatory requirements. The new Standard is structured by reference to different components of the tech stack—models, platform services, and applications—and the role that Microsoft plays in developing or deploying those components. It combines core requirements that always apply with more targeted, scenario-specific requirements that can evolve as capabilities and risks change. For example, we apply some of our most rigorous risk management measures to AI systems with the most significant cyber capabilities, helping ensure that advances in AI favor the defenders responsible for securing critical digital infrastructure.

We are also evolving our technical risk management practices. Increasingly capable systems can retain memory, use tools, access data, and take actions on behalf of users. Governing these systems requires us to think beyond the behavior of an individual model or application to interactions among models, agents, applications, tools, data, and people. Our work increasingly focuses on controls such as agent identities, tool permissions, and monitoring of actions.

And governance only works when people can put it into practice. We have continued to build responsible AI capabilities across Microsoft, equipping thousands of engineers and product managers with training on topics such as agentic AI threat modeling and prompt injection defenses.

Together, these investments are helping us move toward a more continuous, lifecycle-based approach to AI governance. With agentic AI, risks can evolve as systems interact with their environments, users, and other systems. Our governance needs to evolve with these agentic capabilities—and incorporate what we learn from their testing and deployment.

Practical tools and capabilities

Effective governance depends on tools that help translate policy goals into action. As developers and organizations navigate a more complex technical and regulatory environment, they need practical ways to identify risks, evaluate systems, establish controls, and monitor how AI behaves in the real world.

We are applying what we learn from governing AI at Microsoft into tools, capabilities, and resources that help developers and organizations beyond Microsoft do just that—whether they build on our platforms or leverage open-source projects.

We have expanded tools to evaluate AI systems across the lifecycle. A new AI Red Teaming Agent helps accelerate the identification and evaluation of risks. Agent evaluators help developers measure the quality, safety, and performance of agentic applications. RAMPART turns red team findings into repeatable tests, enabling more continuous coverage as systems change.

We are also building greater visibility and control into agentic systems. With ASSERT and Agent Control Specification, developers can evaluate agents against their policies, place runtime controls at critical points in an agent’s workflow, and monitor behavior.

These tools and capabilities reflect a shift: as systems become more dynamic, governance needs to become more operational. Organizations need to be able to see what their systems are doing, test how they behave, and intervene when necessary—not just assess them before deployment.

Organizations also need confidence—and increasingly need to demonstrate—that responsible AI practices are being implemented consistently. Microsoft is one of the few companies certified against ISO 42001 across a broad portfolio, including Microsoft 365 Copilot, Foundry, and GitHub Copilot. Over the last year, we have simplified and strengthened our internal processes that support that certification.

Ultimately, responsible AI governance is a shared responsibility across the AI value chain. Our goal is to help make the practices and capabilities needed to meet that responsibility more accessible, practical, and scalable.

Shared practices and strong partnerships

The challenges of governing AI are bigger than any one company, and increasingly interconnected AI systems make collaboration even more essential.

As AI adoption expands across borders and sectors, we need shared expectations for how systems are evaluated, monitored, and governed, as well as interoperable standards that enable visibility into interactions across tools, data, and systems. We also need to keep advancing the underlying science and technical practices so that we can benefit from rigorous, applied insights into what effective governance looks like and where the remaining gaps are.

That starts with research. Over the past year, we advanced our work with the US Center for AI Standards and Innovation and AI Safety and Security Institutes in Australia, Singapore, and the UK to strengthen the science and practice of AI evaluation. We also launched an External Red Team Alliance with 18 universities across six continents to expand understanding of priority risks.

Common technical practices and standards are critical. Through the Frontier Model Forum, OpenTelemetry, and the Appia Foundation, we are helping develop approaches spanning frontier cyber benchmarks, end-to-end observability for increasingly agentic systems, and AI assurance across supply chains and sectors. We are also contributing to efforts that make transparency reporting more interoperable across organizations and jurisdictions, including through an OECD-led informal task force that developed the Hiroshima AI Process Reporting Framework version 2.0.

We also need shared ways to measure progress. We cannot meaningfully assess progress if every organization measures AI risks differently. Through our work with MLCommons, we are helping expand AILuminate into a broader suite of reliability benchmarks, creating common approaches for evaluating areas such as jailbreak resilience, multilingual performance, and psychosocial risk in conversational AI.

Shared learning, shared practices and standards, and shared measurement can help the entire ecosystem develop while raising shared expectations for trust.

Meeting the moment and investing for the future

Our experience over the past year has reinforced that responsible AI cannot be static. It has to be embedded in development processes, supported by practical tools, and continually informed by what we learn. That is why our responsible AI investments extend from the systems we build, to the tools we provide our customers, to the research, practices, and measurement approaches we help develop with the broader ecosystem.

Our 2026 Responsible AI Transparency Report explores this work in more depth—from how we re-engineered our Responsible AI Standard to how we are strengthening governance for agentic AI, advancing evaluation, and addressing AI misuse. We invite you to explore the report to see what we have learned, what we have changed, and how we are putting our priorities into practice.

As AI becomes more powerful and more present in people’s lives, our commitment is to keep listening and learning, to keep strengthening our safeguards, and to keep putting the empowerment of people and organizations at the center of our strategy.

The post Responsible AI in 2026: How we are adapting for what’s ahead appeared first on Microsoft On the Issues.