Painfull logon just after logoff a precedent session

[buijspa]

Hi,

Sometimes, just after a logoff from a previous session, users are waiting +/- 10 minutes on "Applying audit Policy..." at logon before receiving their desktop (event viewer : GPO users applied event 1503 : user ProcessingTimeInMilliseconds 682484).  It seems that something is waiting for a timeout from the previous session. We are on the latest version (9.1.0.175).  If we wait between 2 consecutive sessions, no problem.

Found in logs-1.log :  Logging to this file because configured log file '\\XXX\UEM_PROFILE\buijspa.DOMAIN\logs.log' is in use.

Any idea?

Thanks,

buijspa

[DEMdev]

Hi buijspa,

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 (9.1.0.175).

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.

[Lieven]

Hi UEMdev,

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)

[Pim_van_de_Vis]

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?

[Lieven]

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:

Import:

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

Export:

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.

[Pim_van_de_Vis]

Hi,

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.

Client caching features: Oplock vs. Lease – Microsoft Open Specifications Support Team Blog

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.

Pim.

[Pim_van_de_Vis]

Some more information from the EMC documentation:

EMC Community Network - DECN: Isilon OneFS fundamentals of locks and locking

"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.

[DEMdev]

In case anyone finds this older thread while search for "slow" or "oplocks" , please take a look at Re: UEM hanging/delaying randomly.