DEM Conditions Performance

[cstalhood3]

Are there any best practices to speed up DEM condition evaluation? Is there any performance difference between condition and condition set? How to performance optimize large numbers (hundreds, or thousands) of DEM User Settings each with unique conditions, especially AD group membership?

[DEMdev]

Hi cstalhood3,

The result of evaluating a condition set is cached ([DEBUG] Conditions: Condition set 'demo' was previously evaluated to true), so if you reference the same condition set in fifty config files, the underlying conditions will only be evaluated once during a path-based import, for instance. This caching is "per run", so that condition set will be re-evaluated for each DirectFlex refresh, UEM refresh, and DirectFlex import/export, and also at the path-based export.

Having said that, evaluating conditions is typically not a time-consuming activity, as most of them are simple registry lookups or cheap Win32 calls. Group membership lookup should also be fast, as Windows will just check the user's token; we're not performing AD lookups or anything like that. The only possible outlier might be the Exit code condition, as we can't control what happens there .

If you have thousands of items, just reading and processing them will definitely be noticeable. I can't really imagine that condition evaluation would play a role there, but would be very interested to hear if your findings are different.

[cstalhood3]

I added 600+ Folder Redirection items, each with unique Active Directory group membership conditions. Simply evaluating the conditions added quite a bit of time to login.

I then changed to a script method of evaluating group membership instead of DEM conditions and it shaved 60 seconds from the logon time.

DEM evaluates Folder Redirection before it evaluates variables so I can't use new variables in Folder Redirection actions?

[DEMdev]

Hi cstalhood3,

I added 600+ Folder Redirection items, each with unique Active Directory group membership conditions. Simply evaluating the conditions added quite a bit of time to login.

Just to make sure I understand correctly: that "quite a bit of time" was due to those group membership conditions, rather than "just" those 600+ folder redirection settings files?

DEM does indeed process folder redirection settings before environment variable settings, but you might be able to leverage the Pre-execution Command advanced setting (see KB 2145286 for Group Policy-based configuration, and KB 2148324 for NoAD mode.)

With that setting you can run a script very early during DEM's logon processing. Environment variables set in that script will be available for use in DEM settings, as long as you set them with SETX.exe to ensure that they survive beyond the lifetime of the script.

[cstalhood3]

Those 600+ files each have unique Active Directory group membership conditions. If I turn on Debug logging, then I can see the delays as it evaluates each group.

In my replacement script, I use the "whoami" command to get the list of groups and compare it to a CSV lookup file and then set variables that I use later. Much faster.

[DEMdev]

Those 600+ files each have unique Active Directory group membership conditions. If I turn on Debug logging, then I can see the delays as it evaluates each group.

I'll try to do some performance tests soon, thanks.

[cstalhood3]

I just moved 200 shortcuts from DEM into Group Policy Preferences and that reduced logon duration by over 20 seconds. Most of them had unique AD group conditions, but Condition Sets did help a couple seconds.