users are waiting +/- 10 minutes on "Applying audit Policy..." at logon before receiving their desktop
That's a Windows message, so I don't know how UEM is involved in that delay. Can you provide a UEM log file at DEBUG log level, covering a full session from logon till logoff?
We are on the latest version (184.108.40.206).
Just as an FYI: not that it really matters (in that there are no known issues in that release that would explain the behavior you're seeing), but that is by no means the latest version. UEM 9.1 dates back to the fall of 2016; we're currently at 9.3, which came out in early January of this year.
I am working with buijspa on the same case.
We are using UEM 9.3
This morning we logged on / logged off several times wit the same user to the same pool and had different results. One time UEM import took > 10 minutes and UEM export took 3 seconds, another time the UEM import took less then 3 seconds, but the UEM export took 9 seconds.
We were using the same pool, the same user, we did not do anything within the VDI (so no profile changes).
The problem not only occurs just after logoff a precedent session, but also when teh previous session was logged off hours before.
Attached are the debug log files for the two attempts (logsOK.zip and logs.zip)
There seems to be 10 seconds delays between processing of each file.
Could it be that you are using EMC Isilon for offering the SMB fileshares?
If so, could you try disabling "opportunistic locking" (oplocks) on Isilon?
The SMB UEM fileshares are hosted on an EMC Unity 500
We have tested with disabling/enabling the opslock on the UEM shares and here are the results:
Test1 - Opslock disabled ==> 3,0 Secs
Test2 - Opslock disabled ==> 3,2 Secs
Test3 - Opslock disabled ==> 3,4 Secs
Test4 - Opslock disabled ==> 3,0 Secs
Test5 - Opslock disabled ==> 3,2 Secs
Test6 - Opslock enabled ==> 2,4 Secs
Test7 - Opslock enabled ==> 471 Secs
Test8 - Opslock enabled ==> 2,6 Secs
Test9 - Opslock enabled ==> 2,5 Secs
Test10 - Opslock enabled ==> 2,4 Secs
Test1 - Opslock disabled ==> 9,4 Secs
Test2 - Opslock disabled ==> 2,6 Secs
Test3 - Opslock disabled ==> 9,4 Secs
Test4 - Opslock disabled ==> 9,4 Secs
Test5 - Opslock disabled ==> 9,6 Secs
Test6 - Opslock enabled ==> 593 Secs
Test7 - Opslock enabled ==> 2 Secs
Test8 - Opslock enabled ==> 9,3 Secs
Test9 - Opslock enabled ==> 9,1 Secs
Test10 - Opslock enabled ==> 9,0 Secs
So since opslock disabling gives more consistent results we are going to disable opslock and monitor further.
Good to hear, but I would like to know why this happens. I've seen it before a couple of times, but only on EMC SMB file shares.
I found this good article that describes Oplocks and explains it a feature from SMB 1 and 2.0.
With SMB 2.1 this feature is replaced with a feature called 'Lease'.
Could it be that you are still offering SMB 2.0 fileshares? Is it possbile to offer SMB 2.1 or 3.0 shares from the EMC SAN?
If so, can you please test if that also solves the problem?
Hope to hear from you.
Some more information from the EMC documentation:
"SMB2.1 and later – oplocks are still supported but leases are also included in the protocol. These offer a number of improvements over oplocks. These are fully supported in OneFS."
Not sure if you still need to manually disable Oplocks when you offer SMB 2.1 or newer file shares, since it is still supported. But reading from the documentation EMC says Leases offer improvements over Oplocks, so once upgraded to SMB 2.1, it seems valid to disable Oplocks.