Hmm good point. I will try that later on in my lab and report back.

I'm going to guess that is the default setting, as that is how my share is setup as well.  I've altered it to not allow any caching and will see if this has any effect. 

Thank you .

I changed both the UEM_Profiles and UEM_Config shares to "No files or programs from the shared folder are available offline", but nothing changed unfortunately. Still seeing the "OPLOCK BREAK IN PROGRESS" that causes a 18sec. delay.

Thanks, Ivan.

I'm currently running continuous logons and logoffs for two concurrent users with all 200+ Flex config files from the VMware Marketplace. The delay between logon and logoff differs for the two users, so the session "overlap" changes slightly for each run. So far I have not seen any delays after 100+ iterations.

Have done the same with both users concurrently performing a DirectFlex refresh in a tight loop; no delays seen yet after 400+ iterations.

My VMs are Windows 10 Version 1809, my file server is 2012R2, and I verified that SMB 3.02 is being used. I did not tweak any SMB settings, and left the caching configuration for both config and profile archive shares at the default "Only the files and programs that users specify are available offline".

ProcMon on the file server is showing lots of oplock-related entries, but no "OPLOCK BREAK IN PROGRESS". Just oplocks being requested, granted, not granted, closed, successful FSCTL_OPLOCK_BREAK_NOTIFY, etc. None of them seemingly causing a delay.

The repro attempt continues...

I've been watching this and I haven't seen this in my environment, but I just was wondering in general is islion storage used where its occurring? I found a post awhile back about the same thing happening . I saw one person mention they were using it so just wanted to make sure that was something being looked at.

Hi sjesse,

There have been some reports with Isilon, but both Sabian0309 and ijdemes are using standard Windows file servers.

The previous Isilon reports have never been analyzed in detail, as far as I'm aware – oplocks have frequently come up as a potential culprit, but apart from JohnTwilley's recent post in this thread, I haven't seen anything conclusive...

You can read the old thread from 2017 regarding my Isilon File locking issues:  https://communities.vmware.com/thread/566801

My company's Isilon slowness with UEM was resolved by disabling OpLocks on the shares.  We had EMC Support working the case, and they mentioned it was a common issue.  So much so, that the ticket was only open for like 1 day.

Ok , figured I'd check, I've been watching this as I've see delays like this in earlier windows versions and I been running procmon traces and haven't seen what you are looking into on my windows 2012 r2

Hi UEMdev​,

Did you use the Win10 v1809 SAC release without OSOT? So just next-next-finish? I am running v1809 LTSC with OSOT. Will try without OSOT as well, just to be sure.

BTW, I also have VM running (v1809 LTSC with OSOT) in VMware workstation (no Horizon) and experience the same issues there. Also the traces are the same compared with the ones from VDI.

Hi ijdemes,

Yes, Windows 10 Version 1809 Enterprise, next-next-finish installs. No OSOT, no Horizon.

Allright, I will check with the same version/setup and see if I get a different result compared with my original version/setup.

Just tested with v1809 Enterprise, no OSOT, no Horizon, but still the same result. Thinking of what to test/rule out next... :smileyconfused:

Hi ijdemes,

Thank you for your additional testing. I ran another 10000 DirectFlex refreshes on two VMs in parallel last night – no delays...

Thinking of what to test/rule out next...

Same here...

Hi ijdemes,

Responding to an older message of yours:

I am runnning vSphere 6.7 U1, VMware Tools 10338, vmxnet3 driver version 1.8.3.1.

I'm on 6.5U2, VMware Tools 10.2.1, and vmxnet3 1.7.3.7. That is, where vmxnet3 is used, it's 1.7.3.7 – I just noticed that my file server and one of the VMs are using E1000e adapters, and hence Intel drivers. Can't imagine that affecting SMB behavior as that's a few OSI layers up, but I'll change the config and will upgrade VMware Tools. I'll stick with 6.5U2, though

Hi ijdemes,

No change in test results after switching to vmxnet3 on all NICs and updating to VMware Tools 10.3.10...

Bummer! I will also test with Server 2012 as a file server. Just trying to rule out another component/version.

Did a test with Server 2012 as a file server, but still the same result. :smileyconfused:

I created a (Win2016) file server that was not hosted on vSphere and VDI desktops that were not hosted on vSphere. Still experiencing the same result. I think I (sort of) ruled out the underlying hypervisor (vSphere) at the moment (OK, maybe I don't know what the look at next for this component ). Focussing on the client/Windows (VDI) part now.

Thanks, ijdemes! I've been switching between NoAD, running FlexEngine as a Group Policy client-side extension, and running FlexEngine from a logon script, without any change in behavior...

What Group Policy settings do you have configured? My setup is very empty, with computer policies for detailed status messages, disabling the logon script delay, always wait for network, and running logon script synchronously.

User policy contains logon and logoff scripts for UEM (where appropriate), and the relevant UEM configuration.

Where do you run the Management Console? Mine runs on the file server itself, so probably does not use SMB.

My VMs have 2 vCPUs; overall performance of my environment is not great (pretty old ESX box that runs quite a few VMs.)

Pretty much at a loss what to try next...

I've got the same policy settings in place. Nothing fancy .

In the mean time I did a Wireshark trace on the file server resulting in a Create Response Error: STATUS_PENDING message

Eventually the connection is reset, which takes about 19 seconds that corresponds with the delay in the FlexEngine.log file.

Not seeing yet why this happens though....