Windows Store submitted app behaviour

Hi @Raja Shanmugam ,

Thank you for taking the time to go through both the AppEnforce.log and the event logs.

On AppLocker: I'd steer you away from it here. A rule for a packaged app controls both the installation and the running of the app (Create a rule for packaged apps). And by default, AppLocker policy only applies to code launched in a user's context (AppLocker), while background package servicing doesn't run there.

So the likely result is the opposite of what you want: users already on 1.1.0 get blocked from launching the app, and nothing rolls back to 1.0.0.

A more precise log check

The event is Event ID 400 in AppXDeployment-Server > Operational, and the useful detail sits in the full event data rather than the summary text. Run this in an elevated PowerShell session:

Find the row where PackageFullName matches your package at 1.1.0.0, then look at two fields:

• PackageSourceUri tells us the delivery channel. On a test machine, packages coming through Windows Update showed an x-windowsupdate:// prefix.
• CallingProcess names the process that started the deployment, with values like svchost.exe,wuauserv. If yours names your own application executable instead, that points to an app-initiated update.

Two things so the output doesn't mislead you: CallingProcess can legitimately come back blank, and I couldn't find official Microsoft documentation for that field, so I'd weight PackageSourceUri more heavily. If the log has already wrapped past the date the version changed, let me know.

Could you check whether the 1.0.0 build calls any of the Store update APIs from Windows.Services.Store, GetAppAndOptionalStorePackageUpdatesAsync with either RequestDownloadAndInstallStorePackageUpdatesAsync or TrySilentDownloadAndInstallStorePackageUpdatesAsync?

These let an app install its own Store-delivered updates in code (Download and install package updates from the Store), which is a different path from the background auto-update that AutoDownload = 2 controls. Worth noting the silent variants only work if Update apps automatically are enabled in the Store and the device isn't on a metered network, so in your environment the prompted variant is the more plausible one.

Since your team owns the code, a quick check on your side would settle this faster than the logs will.

For troubleshooting, do you have a spare or test device that could work on? Ideally one still on 1.0.0 with the same policy configuration as the affected machines. If it's possible on your side, these two checks would tell me the most:

1. Dev team: whether 1.0.0 calls any of the Store update APIs above.
2. One affected device: the PackageSourceUri and CallingProcess values for the 1.1.0.0 entry.

Please remove device names, account details, and internal paths from anything you share.

Any additional details you can share would be helpful in narrowing this down and determining how best to assist you further.

Hi,

The registry entry seems to be misconfigured.

HKLM\SOFTWARE\Policies\Microsoft\WindowsStore\WindowsUpdate AutoDownload 2

PackageSourceUri x-windowsupdate://C1384193-0D98-49AF-AEB9-54F40AA6AF6D/79E46A24-E0C6-41D9-9EA3-E566B4D6B30D/72cbf8e0dfd7a7931d4d8141f9fe9ddabfc95ae5

CallingProcess svchost.exe,wuauserv

They do not want to block the updates for all the app.

It is required only for specific app. Lets say if we create a new Applocker -> Packaged App Rules -> Create Default Rules and create Deny Rule for App >1.1.0. Atleast this will stop the future updates. (We could test this in test machine without pushing policy through group policy).

They can continue to use 1.0.0 and 1.1.0. when 2.0.0 is released in store GA that update will be blocked.

or is there any other way to block automatic update for specific app?

Hi @Raja Shanmugam ,

Thanks for clarifying and there is a setting built for exactly this case. DoNotUpdate in the EnterpriseModernAppManagement CSP blocks automatic Store updates for one specified app, without the device-wide block.

Microsoft documents this in Manage apps - Prevent app from automatic updates. The setting excludes the specified app from automatic Store updates without imposing a device-wide update block. Other apps remain subject to their existing update policies.

Configure the exclusion for your app

For this scenario, use the device-scoped setting below, following Microsoft's enterprise app-management guidance. Replace {PackageFamilyName} with your app's actual package family name:

./Device/Vendor/MSFT/EnterpriseModernAppManagement/AppManagement/AppStore/{PackageFamilyName}/DoNotUpdate

• Data type: Integer.
• Value: 1 to block automatic updates for that app; 0 to clear this particular block.
• Use the package family name, not the MSI product code or version-specific package full name.

The CSP reference documents these values and the supported Windows versions/editions. This is a package-family exclusion, not a version ceiling: it does not allow automatic updates up to 1.1.0 and block only later versions.

Microsoft also documents that offline-package updates remain possible. That fits your intended deployment model, but your MSI wrapper's upgrade behavior still needs to be verified on a test device.

Since you deploy through SCCM, the next step is to select the configuration route. If the devices are also MDM-managed, the setting can be delivered through that channel. For local configuration, a documented option to investigate is the WMI Bridge Provider; Microsoft also documents a class exposing DoNotUpdate. Device-scoped WMI Bridge changes require LocalSystem, not merely an elevated administrator session. Your SCCM administrator should validate the applicable class and package instance on the target Windows build before deployment.

About the registry finding

The extra WindowsUpdate subkey is significant. The documented location for AutoDownload is directly under:

HKLM\SOFTWARE\Policies\Microsoft\WindowsStore

If AutoDownload = 2 exists only under WindowsStore\WindowsUpdate, it does not configure that documented policy. Your x-windowsupdate://... source and svchost.exe,wuauserv caller is consistent with Windows Update delivering the package, although they do not establish the effective policy at that time.

The documented AutoDownload policy is device-wide, so using it to block updates would not meet your clarified requirement.

About AppLocker

Your revised AppLocker range, strictly above 1.1.0.0, would leave 1.0.0.0 and 1.1.0.0 outside that deny range.

I should also correct my earlier response: it was too categorical about AppLocker and background servicing. Microsoft documents that a packaged-app rule controls both installation and execution. Depending on the rule's scope and enforcement, a matching future version could also be blocked during your approved MSI deployment or when users launch it. You would need to review and adjust the rule as necessary before approving that version.

It is not an automatic-update-only control, so I would test DoNotUpdate first.

Validate on an isolated test device for troubleshooting

1. Start with an older version installed while a newer version is available in Store. Apply the per-app exclusion before allowing automatic updating to run.
2. Read back DoNotUpdate and confirm it is 1. This checks the configuration; it does not by itself prove that automatic updates are blocked.
3. During normal automatic updating, check that your app stays unchanged and another Store app with an available update can still update.
4. Separately, test the approved MSI upgrade when it is available.

An already-current installation staying unchanged would not demonstrate that the exclusion works.

If you try this and run into anything unexpected, let me know and I'll help you from there.

Hi @Gatlin Le (WICLOUD CORPORATION)

I have done the DoNotUpdate to 1. And i could see its updated to 1.

Now how do we verify update is blocked apart from manally verifying the version from app.

I have checked into EventViewer - > DeviceManagement-Enterprise-Diagnostics-Provider and also

AppxDeployment-Server/Operational.

i do not find logs related to the update being blocked. I will wait for some more time to check the logs. (previously for AppLocker, i could see app being blocked to update because of policy)

Meanwhile can you let me know where to find information that update has been blocked?

Get-CimInstance -Namespace root\cimv2 -ClassName __Namespace | Where-Object Name -eq "mdm"
Name PSComputerName
---- --------------
mdm
Get-CimInstance -Namespace root\cimv2\mdm -ClassName __Namespace
Name   PSComputerName
----   --------------
dmmap
$Namespace = "root\cimv2\mdm\dmmap"
$ClassName = "MDM_EnterpriseModernAppManagement_AppManagement01_02"
$AppPFN = "13AB8GDA.AppPFN"

$AppInstance = Get-CimInstance -Namespace $Namespace -ClassName $ClassName | Where-Object { $_.InstanceID -like "$AppPFN" }
#Enable DoNotUpdate (1 = True)
if ($AppInstance) {
$AppInstance.DoNotUpdate = 1
Set-CimInstance $AppInstance	
$AppInstance -VerboseWrite-Host "DoNotUpdate applied successfully to $AppPFN"
}
else
{
Write-Host "App instance not found in MDM Bridge. Ensure the app is registered on the device."
}


Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_EnterpriseModernAppManagement_AppManagement01_02" | Where-Object { $_.InstanceID -like "*$AppPFN*" }
DoNotUpdate                           : 1
InstanceID                            : 13AB8GDA.AppPFN
MaintainProcessorArchitectureOnUpdate : 0
ParentID                              : ./Vendor/MSFT/EnterpriseModernAppManagement/AppManagement/AppStore
PSComputerName                        :

Hi @Raja Shanmugam ,

Thanks for sharing the readback and checking the event logs.

Regarding your logging question, I could not find a Microsoft-documented event ID or log channel that records each update excluded by DoNotUpdate in the EnterpriseModernAppManagement CSP documentation. I therefore cannot point you to a documented “update blocked” event equivalent to the AppLocker event you saw. This does not mean Windows never records the decision; the absence of an entry in the two logs you checked does not, by itself, indicate success or failure.

You can record the installed package version without opening the app using Get-AppxPackage. In an elevated PowerShell session, set $AppPFN to the actual package family name used in your script, then run this before and after the observation period:

$AppPFN = '13AB8GDA.AppPFN' # Replace with the app's actual PackageFamilyName
Get-Date -Format o
Get-AppxPackage -AllUsers |
    Where-Object { $_.PackageFamilyName -eq $AppPFN } |
    Select-Object PackageFamilyName, Version, PackageFullName

Keep the full output from both runs and compare the same package family on the same test device. If multiple entries appear, retain all of them rather than comparing only one row. If the query returns no package, check the package family name and installation context; an empty result is not evidence that an update was blocked.

For a meaningful test, the device needs an older installed package and a newer, compatible version available to it through the Store. Apply DoNotUpdate = 1 before normal automatic updating occurs. An unchanged version is useful evidence, but not conclusive on its own if the device’s opportunity to receive the update has not been established.

If you need a stronger comparison, use two isolated test devices with the same older version and otherwise matching configuration:

1. Keep DoNotUpdate = 1 on one device and set it to 0 on the control. The control is intentionally allowed to update; do not make this change on production devices.
2. Ensure no other policy, such as a device-wide Store update block or an AppLocker version restriction, prevents the comparison. Observe normal background updating, not a manual Store update action.
3. Compare the timestamped package-version outputs. If the control receives the newer version while the excluded device does not, that supports the per-app setting working. If neither updates, the result is inconclusive.

Separately, test that your approved MSI still upgrades the app as intended. This checks the other part of your requirement: retaining the approved deployment route.

If the excluded device updates despite that setup, please share a fresh DoNotUpdate readback, including ParentID and InstanceID, along with the before-and-after package versions and timestamps. Remove identifying details while keeping the package identifier consistent across the excerpts. That will give me a specific update to investigate rather than relying on the absence of a log entry.

Hi,

I will observe and let you know.

Also in the same enterprise environment, in some machines the InstanceID of the app is not listed at all, but the app is installed. then it might have problem right? why app is not listing in some machines? do you have any idea?

$Namespace = "root\cimv2\mdm\dmmap"
 $ClassName = "MDM_EnterpriseModernAppManagement_AppManagement01_02" 
$AppPFN = "13AB8GDA.AppPFN"  

Get-CimInstance -Namespace $Namespace -ClassName $ClassName

#Example
DoNotUpdate                           :
InstanceID                            : MicrosoftCorporationII.QuickAssist_8wekyb3d8bbwe
MaintainProcessorArchitectureOnUpdate : 0
ParentID                              : ./Vendor/MSFT/EnterpriseModernAppManagement/AppManagement/NonStore
PSComputerName                        :

Hi @Raja Shanmugam ,

Thanks for the update. The Quick Assist entry shows that the WMI Bridge query returns instances on that machine, but it does not tell that why your app’s package family is missing. I cannot yet determine whether the difference comes from how the package is installed or registered on those devices, the query context, or Windows app inventory.

Could your endpoint team compare one machine where your app’s InstanceID appears with one where it does not? The most useful details are the app’s actual PackageFamilyName and PackageFullName from Get-AppxPackage -AllUsers, how the MSI installs or registers the package, and the InstanceID, ParentID, and DoNotUpdate values returned when the device-scoped WMI Bridge query runs under LocalSystem. Please check the entries for your app specifically; the Quick Assist NonStore entry does not establish which branch your app uses. Microsoft documents both the app inventory classifications and the LocalSystem requirement for device-scoped WMI Bridge settings.

I can help interpret a comparison shared here with device and organization details removed, but I cannot inspect your devices or deployment configuration through this public thread. If the comparison points to the Partner Center preinstall kit or Store submission rather than a device-side difference, you can raise that package-specific question through Partner Center support.

I’m happy to help interpret any findings you can share here within the scope of this forum. If you have any questions as you compare the devices, please feel free to ask.

Hi,

please ignore some machines the InstanceID of the app is not listed at all.

I am still monitoring changes after the DonotUpdate for PFN update from the powershell script.

Hi @Raja Shanmugam ,

Thanks for the update.

While you're monitoring, one thing worth keeping in mind so the result is conclusive: the device needs to be on the older version while a newer, compatible version is actually available to it through the Store. If the package is already current, an unchanged version won't tell us much either way.

Capturing the package version with a timestamp at the start and end of the observation period gives you something concrete to compare, rather than relying on the absence of a log entry.

Since this kind of observation can take a while depending on when the Store servicing cycle runs, would you be comfortable if I archive this post for now? Nothing is lost by doing so and whenever you have results or anything new comes up, just reply here and I'll pick it straight back up with you.

Take the time you need. When you have results, share them here and I'll help you interpret them.

Hi @Gatlin Le (WICLOUD CORPORATION)

Apart from pushing the policy from IT through Intune or via script, For the future MSI installer version, can we include the powershell script to set DoNotUpdate option from the installer itself ( for other customers as well)?

Will there be any issue? which approach is good?

Hi @Raja Shanmugam ,

Yes, it is technically possible to include logic in the MSI that sets DoNotUpdate = 1. However, I would make this an explicit administrator-selected option rather than enable it silently for every customer.

For your current SCCM-managed environment, I would recommend keeping this configuration under the endpoint team's control through the existing deployment workflow. For other customers, an optional installer setting or a separate documented configuration script would make the intended update behavior clear. This is a deployment-design recommendation, not a requirement to use Intune.

If you integrate it into the MSI, the device-scoped WMI Bridge operation must execute as LocalSystem. For an MSI custom action that changes this setting, use deferred execution without user impersonation, with the necessary installation privileges. Verify the script's actual execution identity rather than assuming that launching an elevated MSI is sufficient.

The implementation should confirm that the target PackageFamilyName instance is available before modifying it, read back DoNotUpdate afterward, and log the outcome. If the instance is unavailable or the operation fails, the installer should clearly report that the configuration was not applied rather than report that automatic updates have been disabled.

Also define how the setting is handled during upgrade, repair, failed-install rollback, and uninstall. Do not assume MSI rollback automatically reverses the WMI change; any required rollback behavior needs to be explicitly designed. Avoid automatically clearing or overwriting a setting managed by the customer's IT team. Agree on a single management owner so that the installer and endpoint-management configuration do not independently enforce different values.

Before distributing the option, validate the supported Windows editions and builds, the Store automatic-update exclusion, and the intended MSI upgrade behavior. Microsoft documents that offline-package updates remain possible with the exclusion, but the specific MSI upgrade path still needs validation in the intended deployment environments.

Please let me know whether this addresses your MSI integration question.

I understand that confirming the automatic-update behavior will take some time, since it depends on the Store servicing cycle in your environment. When your monitoring shows results, or if any unexpected update behavior comes up, feel free to open a new question and include a link to this thread for context. A fresh thread will be easier to follow, and I am happy to continue looking into it with you.

If you found my explanation above was truly helpful or informative to you, I would greatly appreciate it if you could follow this guidance so others with the same issue could benefit as well.

Thank you.