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.