What exactly will happen when i click on "Expand" in the Import/Export tab?
Why i am asking is this: When i upgrade UEM to a newer version i assume that there will be new or updated templates for various components/settings. For example, in the latest v9.4 update the release notes mentioned:
However when i take a look at the startmenu.ini file in my current setup that has already been upgraded to v9.3 and later to v9.4, this file is still mentioning v9.2:
"This file was created using VMware UEM Management Console version 9.2.0.701."
Besides that, it looks like there are no changes inside the .INI file
This makes me believe that when i click the Expand button, the underlying template is not upgraded during a UEM upgrade and thus is missing the new settings for this new build? Is this the right assumption?
Hi SummaCollege,
Checking what has changed in the definitions of the built-in settings is a manual process, unfortunately: create a new config file based on a Windows Common Setting or Application Template, Expand it, and compare it to your own config file... (Which is probably what you had in mind already 🙂
There's definitely things we can improve in this functionality. The problem, as is so often the case, is that we have limited resources. Compare functionality would be cool, but is most probably not going to happen – too much effort for something with limited value (in that there is not a lot of customer demand for this). I'll keep track of your interest, though.
However, it might be feasible to at least keep track of the fact that a Flex config file was originally created based on a built-in setting which was then expanded, and at least notify you in case that setting is subsequently updated. No guarantees as to when or whether this might happen, but I'll definitely give it some thought.
Happy to receive feature requests, no worries!
Hi SummaCollege,
If you create a Flex config file based on a Windows Common Setting or Application Template, we keep a reference to the built-in definition. If those built-in settings are updated in a later release, you're prompted to upgrade the Flex config file:
When you Expand a Windows Common Setting or Application Template, we replace the reference to that setting by its definition, which means that your Flex config file will now contain readable registry and file system sections. However, the Flex config file no longer has a reference to the built-in definitions:
This means that you won't be notified of future updates to the built-in settings, so your assumption is correct.
As for the Windows 10 Start Menu Windows Common Setting: that did not exist before UEM 9.4, so I guess your startmenu.ini file was created "manually".
Hi UEMdev,
Thank you for this clarification and confirmation!
One question i have is: how do we deal with updated templates that contain bug fixes and/or added functionality (for new Windows 10 builds for example), when using expanded settings?
I think i know how, but lets see if my feeling is right
A nice addition would be a compare function that would enable you to compare your current settings with the built-in template. We completely understand you can't upgrade expanded settings as most of the time those settings have been altered to fit the needs of the customer. The downside of the process as is, is that the customer is missing out on the changes and has no easy straightforward way to view the changes and template settings.
:smileyplus: Please see this comment as positive feedback as we like the product and like to see it get even better..
Greetings!
Btw i reviewed my changes logfile (i always write down all changes) and you were spot on about that startmenu.ini. It was indeed created manually in the early Windows 10 era when we started using UEM and were struggling to get all that W10 stuff functioning.
Hi SummaCollege,
Checking what has changed in the definitions of the built-in settings is a manual process, unfortunately: create a new config file based on a Windows Common Setting or Application Template, Expand it, and compare it to your own config file... (Which is probably what you had in mind already 🙂
There's definitely things we can improve in this functionality. The problem, as is so often the case, is that we have limited resources. Compare functionality would be cool, but is most probably not going to happen – too much effort for something with limited value (in that there is not a lot of customer demand for this). I'll keep track of your interest, though.
However, it might be feasible to at least keep track of the fact that a Flex config file was originally created based on a built-in setting which was then expanded, and at least notify you in case that setting is subsequently updated. No guarantees as to when or whether this might happen, but I'll definitely give it some thought.
Happy to receive feature requests, no worries!
That manual process is exactly the way we do things, thanks for the feedback. And for the limited resources, looks like we are working for the same company then