We are attempting to package Adobe Acrobat Pro using the MSIX Packaging Tool on a clean Windows 11 Enterprise VM.

Hello Kumar,

Thank you for posting question on Microsoft Windows Forum!

Based on the issue description. Well! The fact of the matter is that MSIX does not fully support complex applications that rely on system-level services like Adobe’s AGSSService. While MSIX Packaging Tool introduced limited service support in Windows 10 (2004) and later, service-dependent applications such as Acrobat Pro often fail post-installation because MSIX cannot replicate all behaviors of traditional MSI/EXE installers. This is an expected limitation rather than a packaging error.

Regarding the query of Limitations or Restrictions. If the service requires a kernel-mode driver (which many Adobe "integrity" and licensing services do), MSIX will fail. MSIX does not support the installation of drivers. For system-level privileges. MSIX services generally run in the context of the user or a restricted local system account within the container. If the service needs to write to protected system directories or modify registry keys outside the virtualized bubble, it will silently fail. Also, services like AGSSService are designed to detect if the application files have been moved, modified, or virtualized. Because MSIX redirects file and registry writes to a "VFS" (Virtual File System), the Adobe service likely triggers a "tamper" flag and shuts the application down to prevent what it perceives as piracy or corruption.

The point worth mentioning here is that Adobe Acrobat Pro cannot be reliably packaged into MSIX due to its dependency on background services like AGSSService. This is an expected limitation of MSIX by design, not a misconfiguration. For enterprise deployment, it is considered to stick with Adobe’s supported MSI/EXE installers or virtualization methods.

You can consult the following articles for more information regarding your concerns.

• https://learn.microsoft.com/en-us/windows/msix/packaging-tool/convert-an-installer-with-services
• https://learn.microsoft.com/en-us/windows/msix/msix-troubleshooting-guide
• https://techcommunity.microsoft.com/blog/modernworkappconsult/packaging-adobe-reader-dc-for-avd-msix-appattach/3572098

Hope the above information is helpful! If it is. Free feel to hit "Accepted" for benefitting others in community having the same issue too.

MSIX supports packaging applications that install and depend on Windows services, but only within the boundaries of the platform and OS version support.

1. Support for applications that install and depend on Windows services

MSIX support for Windows services is available starting with Windows 10, version 2004 and later (including supported Windows 11 versions). Earlier Windows 10 versions (1809, 1903, 1909) do not support Windows services in MSIX packages.

From the feature matrix:

• Windows services in MSIX are not supported on Windows 10 1809, 1903, 1909.
• Windows services in MSIX are supported on Windows 10 2004 and later, and Windows 11 21H2.

Since packaging is being done on Windows 11 Enterprise, the platform itself can support MSIX packages that define services, but the application must be authored correctly as an MSIX service and must comply with MSIX service constraints.

2. Limitations and restrictions for system-level services in MSIX

Key limitations based on the MSIX platform support:

• Windows services are only supported on specific OS versions (Windows 10 2004+ and Windows 11). If the resulting MSIX is deployed to older builds, service functionality will not work.
• MSIX services must be declared and run within the MSIX container model. Traditional system-level behavior (for example, arbitrary system-wide hooks or assumptions about full system access) may not translate directly.
• The MSIX Packaging Tool has specific guidance and support for converting installers that include services, and this support is tied to the OS versions listed in the feature matrix.

These constraints mean that complex, deeply system-integrated services (like licensing or integrity services) may not behave identically when repackaged, even if the capture completes successfully.

3. Recommended approach and whether such scenarios are effectively unsupported

For applications that depend on Windows services:

• Ensure conversion and deployment targets are on OS versions that support MSIX services (Windows 10 2004+ or Windows 11 21H2+).
• Follow the MSIX Packaging Tool guidance for “convert an installer with services” so that services are correctly captured and declared as MSIX services.
• Use a clean VM matching the target architecture and OS (which is already being done) and validate that the service is actually present and running after MSIX installation.

However, MSIX is designed with a more constrained, modern app model. Highly complex, system-level service scenarios—especially those implementing licensing, integrity, or anti-tampering at a deep system level—may not be fully compatible with the MSIX container and service model even when the package builds successfully. In practice, such applications can be difficult or impossible to make fully functional purely via repackaging, and may require vendor support or a native MSIX implementation from the ISV.

Given that:

• The package builds successfully,
• The environment is clean and on a supported OS,
• The app still fails to launch post-install,

this is consistent with the kind of limitation seen when repackaging complex, service-heavy, system-integrated products. While MSIX does support services in general, some third-party service-based applications (such as those with proprietary integrity/licensing services) may not be fully supported by design when repackaged without vendor changes.

References:

• MSIX features and supported platforms
• MSIX Packaging Tool
• Prepare your environment for conversion
• Known issues and troubleshooting tips for the MSIX Packaging Tool
• MSIX App Distribution
• What is MSIX?