UEM Conditions slow to resolve

[pbastiaans]

Seeing an issue where certain conditions are resolving false, UEM configs not applying.

Is there a way to rerun UEM condition check/config apply after applications load, i.e., flexengine.exe /uemrefresh?

[DEMdev]

Hi pbastiaans,

There's a bunch of UEMRefresh variants, but maybe let's first figure out the root cause. What kind of conditions are failing during logon, and why would they be working fine later on? I can't imagine that they're "slow to resolve"; it's probably caused by UEM looking for things that aren't there yet?

[pbastiaans]

The issue we are seeing is that after updating the reference image (Windows Update) and migrating to Office 2016 (may/may not be related), this predefined, fully enforced application configuration with condition 'if folder exist' is no longer working.

It worked immediately after changes, a day later a few users reported the issue, it worked again and then stopped working entirely. I know, weird.

The logs show the condition is evaluating false, I understand why the conditions don't come down. What I don't understand, is why the condition has become flaky to not working.

Another piece, again may/may not be related, mapped drives (via domain logon script) are flaky...works for some, not for others and then next day vice versa.

[DEMdev]

To, umm, state the obvious: the only reason why File or Folder exists would evaluate to false, is in case the file or folder does not exist.

In cases where this condition does not match, is the folder indeed absent? Are you by any chance using App Volumes or some other application delivery mechanism that could cause timing issues?

[pbastiaans]

Folder does exist...by the time the logon process completes and I can browse to it.

It is obvious that it does not exist during the time UEM is running the evaluation. It is an App Volume appstack, it is a timing issue.

I don't understand why it is occurring...what is adding whatever time that it takes for it to now to be not present during the condition check? That's my real question.

[sjesse]

"migrating to Office 2016"

So the file condition checks to see if a specific file for that office version is there if I remember right, check the paths closely, the office 2016 paths are different then the office 2013 paths. Can you share the path, I have it working in my environment I can check tomorrow and see if it matches.

[DEMdev]

It is obvious that it does not exist during the time UEM is running the evaluation. It is an App Volume appstack, it is a timing issue.

That would indeed explain the timing issue, yes.

Maybe you can use a Triggered Task with the All AppStacks attached trigger, to have UEM reprocess certain types of settings once all appstacks have arrived?

[pbastiaans]

Thank you. It is not checking for the Office path, it is checking for path C:\ABC123...this program lives on the root of C:, it is the only app we have that has that requirement.

[sjesse]

Yeah I agree with whats said before then, I've seen this as well, I ended up placing scripts in the startup folder that run in the background that do my own condition checking. That way I know its one of the last things to trigger and the app stacks should be fully applied then.

[pbastiaans]

That is a great suggestion, I may be on an older version of UEM manager I have only 4 options:

1. Lock workstation
2. Unlock workstation
3. Disconnect session
4. Reconnect session

Another person suggested putting flexengine.exe /uemrefresh (or /shortcutrefresh) in the Startup folder. I don't believe either of these reevaluate conditions or apply app config files.

[sjesse]

A list of all the refresh options are here

Additional FlexEngine Operations

UEMDev was suggesting placing one of these in the allvolsattached.bat file  If your not familiar with these take a look at

Advanced App Volumes Agent Configuration

you can run scripts at certain points during the app volume mounting procedure. The issue I see with the uemrefresh flags is it doesn't work for everything so unless one of them fit you just need to get a bit more created. I chose the putting the script it a startup folder, just because its easier to manage then modifying an appstack.

[DEMdev]

UEMDev was suggesting placing one of these in the allvolsattached.bat file

Not exactly 🙂 I was suggesting to use the All AppStacks attached trigger. However, that feature was introduced in UEM 9.4, which was released last May.

For older UEM versions, you can indeed leverage the App Volumes allvolattached.bat (or, as of App Volumes 2.12, allvolattached_shellstarted.bat) scripts. Those serve the exact same purpose as that new UEM trigger, but you would have to create or update them on all your AppStacks.

Putting a script in the startup folder could work as well, but you could also still run into timing issues in case AppStacks are attached asynchronously. In that case, File Explorer might start before the final AppStack has attached, so your script would still be running too soon.

As for the command you should run (through one of those mechanisms): if you want to configure the application that is on your AppStack for DirectFlex, you can have UEM perform a -DirectFlexRefresh. If you "just" want to import application settings at logon (rather than at application launch), that would be a bit harder in this scenario. Happy to provide more details for that, if necessary.

[sjesse]

Which is probably why I'm missing it since I'm still on 9.3, that is a good addition

[DEMdev]

Thanks, sjesse, we thought so, too 🙂

[pbastiaans · Accepted solution]

Thank you both.

What seems to be working is adding these configs, registry settings, to the 'Registry Settings' section of 'User Environment'. The extra milliseconds that are required for this seem to be enough for the condition to evaluate correctly. I can see the condition evaluate false for the config file under 'Personalization', and then later in the log, I can see it evaluate true for this setting.

It's great that there are many creative solutions to this.

I think my question is where are these extra milliseconds coming from? This used to work.

[DEMdev]

Happy to hear you got it to work!

As for why things are behaving differently than before: I guess something in your image update or your Office migration affected the logon timing. Not as satisfying answer, I know...

[pbastiaans]

"Not as satisfying answer, I know..." LOL! Thanks for the effort, the response from the community has been more than satisfying!

I look at it as a band-aid, I'm concerned that there is a root problem that needs to be addressed, as you mentioned 'image update or your Office migration affected the logon timing'.

[DEMdev]

Apart from that typo, I also hate it when I "fix" a problem without knowing what caused it in the first place... I'm happy to apply a workaround if I understand what exactly I'm working around, but that doesn't really apply in this case...

If your conditions depend on something coming from an AppStack, it's really hit or miss, I'm afraid. At logon, UEM runs while App Volumes is attaching its AppStacks (in parallel), and there are a lot of things that might affect the exact timing (AppStack updates, App Volumes agent updates, back-end performance, etc.)

[pbastiaans]

I could not have said it better myself..."I also hate it when I "fix" a problem without knowing what caused it in the first place... I'm happy to apply a workaround if I understand what exactly I'm working around..."

Thanks again for all the help, I'm going to mark the 'workaround' as 'Correct Answer'...hopefully it will help someone else.