UEM Configurations not applying consistantly

[Smoke14]

After upgrading to UEM 9.x, I have noticed the UEM configures have not been completely applied and/or partially applied. Has anyone one into these issues after upgrading?

Couple examples:

1 - Login on Win10 Ent64 check for environment variable I create from UEM management console. Log back out and in on the same zero client and then the Env variable is enabled.

2 - All File Type Associations are not applied either.

3 - Same OS and zero client, we use a default LayoutModification.xml for the start screen (Menu) and some times the all the tiles show and some times they don't all show, but they are in the XML file still.

In this image above you can see the default XML for the StartMenu. The highlight numbered areas are the tiles that do not display some times, after login, even while the entries still exist in the XML.

We are running the following environment (Horizon Info):

This is a link clone pool that refreshes after log-off.

[Raymond_W]

Hi,

Can you post a (scrubbed) UEM logfile in debug ?

Kind regards,

Raymond

[Smoke14]

Logs attached.

[Raymond_W]

Nothing weird in the log files

Maybe it is not completely clear to me, what you are trying to do...

Can you explain a bit more what you try to do and how you've configured it in UEM ?

Also I would like to know what you try to do here

2016-03-30 08:28:25.190 [WARN ] ADMX-based settings were not (fully) processed successfully ('VDI Standard User Settings.xml')

Thanks !

Raymond.

[Smoke14]

Also I would like to know what you try to do here

2016-03-30 08:28:25.190 [WARN ] ADMX-based settings were not (fully) processed successfully ('VDI Standard User Settings.xml')

Here is the Settings:

I kind of put to issues in this thread, so will work with just one of the issues and I will create a new issue for the StartMenu.

I have Environment Variables and File Type Settings not being applied every time I login. Here are the settings;

     Environment Variable Setting:

     File Type Associations Setting:

I will get both of the settings to fail and be successful, then send you the logs.

I'm having issue with AppVolumes now and need to fix that before I can complete the log testing of this issue.

[amarsden]

OK - not sure if this is the same, and I'm still a noob on UEM, so haven't yet ventured as far as logs.  But this happened yesterday -

• I had a profile for application A.exe - it just had default settings.  this worked fine
• program A had a component that needed a new XML license file pushed to the Appdata folder
• Rather than edit the, working, initial profile I set up a new default profile, linked to A.exe for the XML file
• This profile worked, however the initial one stopped - this meant that users failed to get their saved profile stuff when they got a new VPC

I re-did everything, and now have a Partially Enforced component on my initial profile that pushes out the stuff the users shouldn't/can't change and the default bit to push out the defults, but to allow them to have customizations.

But, any ideas why the initial profile failed when I added the second one?

[Pim_van_de_Vis]

When you use the word 'profile' I assume you mean a UEM Config File.

You probably enabled directFlex for the Confif File, but you can only have 1 unique DirectFlex path for your complete configuration.

For example, if you create a Config File called 'Outlook' and you add the DirectFlex executable 'outlook.exe' (not the complete path, just the executable).

And then you create a Config File 'Outlook-2', and you add the same DirectFlex executable 'outlook.exe', UEM no longer knows which Config File it should process when you launch 'outlook.exe'.

This is also logged in the UEM logfile (if set to debug level).

[amarsden]

Yes, sorry, Config Files, not profiles.

Thanks for that - in this case I am pretty sure that I used the complete path - what would happen in that case?

[Pim_van_de_Vis]

Same result. The path to a DirectFlex executable should be unique and can only be configured for 1 Config File to prevent conflicts.

That's why we have the button 'Validate DirectFlex' in the UEM Management Console.

If you press that button it will notify you of the conflict.

See the screenshot:

[amarsden]

Gosh !  - lots of conflicts - if there are a conflict, but the logic applied will always mean only one will work, is that OK?  So Two Configs to the same exe, but both have logic to run for members of a specific (but different for each config) AD group - groups we know that users will only ever be in one as they are location based?

[Pim_van_de_Vis]

That's correct, if you add Conditions to each UEM Config File and make sure only 1 Config File applies to a user, the conflict is not an issue.

[Smoke14 · Accepted solution]

This has been resolved from UEM perspective. This issue was related to Win10 Start Layout and the problem relies on Microsoft.

I will be opening a new discussion on Win10 Start Layout and UEM refresh issues I'm seeing.