How do we handle different types of applicaiton specific data/settings at the enterprise

How do we handle different types of applicaiton specific data/settings at the enterprise



 Oct 18 2018
8 Comments (8 New)
In the backlog

In an enterprise scenario, the data and settings associated with an application could be considered to fall into one of three camps:

  • Data/Settings delivered as part of the application from the vendor that nobody should mess with.
  • Data/Settings configured by IT and deployed as part of application and the end user shouldn't mess with it.
  • Data/Settings configured by IT as defaults, and deployed as part of the application but the end user should be able to modify as needed.

Ideally software vendors would write their products to support these scenarios, but when we are dealing with packaging older applications this isn't always the case.  And I seriously doubt that we can get everything the way I want it to work, but we need to do better than what we have.


I view the current Microsoft proposed process that IT creates a modification package as generally addressing the only the third scenario. Quite possibly the software doesn't expose a setting so the impact might fit the other scenarios, but that is very application specific.  But when it is exposed, it is unclear if there is a way for IT to easily lock it down.  Possibly with files we can mark the file read-only (I'm not sure if this passes through or not), and in the registry I'm also unsure if permissions pass through.


But even if permissions flow through and will be respected, clearly, to me, the idea of IT configuring via a modification package does not allow for IT enforced changes because it is deployed as an add-on package and the end user can just decide to uninstall the add-on to get rid of IT customizations.


I am concerned that this leads to IT opening the package for edit instead of using the modification package, thus loosing the benefits of update.  So we need a better way for scenario 2 to happen, and we still need to also allow scenario 3 where needed so it isn't simple.


I don't have a solution in mind, but maybe someone can propose something.




Tim, #2 feels like a group policy like thing, is that what you are alluding to or something different.

For the comment of users uninstalling modification packages, we added an feature in 1809 for enterprises to be able to prevent uninstall of packages to help with similar types of scenarios.

Status changed to: Needs more info

#2 GPO only applies if app settings are gpo controlled. Most legacy apps are not written with policies.


Glad to hear about the prevention on uninstall. Is that a setting for all apps on the OS/user, or per package granularity? Ok either way, just curious.


The non-removable setting is per app.  Can you clarify #2, is that done through repackaging / scripting and why couldnt a modification package work?

I guess as currently implemented,  for file based settings, a modification package without PSF would actually be static if modification package removal is prevented. So a PSF could then perform a copy on write and redirection for items that should be modifiable; we are better off than I expected on those.


Meanwhile there are registry based settings.  I think these are modifiable, unless registry based permissions work and are used.


Nevertheless, it would be helpful to encourage software vendors supporting MSIX to identify (document) customizable data/settings to help the IT Pro implement their modification package.  IT Pros spend time figuring these out via trial and error, so they'll get it done anyway.  But if Microsoft is doing sessions aimed at ISVs and what they need to do it would be great to include this in the checklist.

Community Manager
Status changed to: New

Note on this.  I have an "issue" listed in the GitHub Repository for the PSF regarding things we might do in this area.  I recently added to the original issue to be more inclusive to this idea, and plan to issue a PR to the FileRedirectionShim as a way to achieve the ideas expressed above.

Status changed to: In the backlog