Here's an example from a user with the highest logon time this morning from vrealize:
2018-01-16 08:27:13.940 [DEBUG] Processed 74 Flex config files (18 successful, 13 skipped, 38 added to DirectFlex cache, 1 disabled, 4 retired)
2018-01-16 08:27:13.940 [DEBUG] Processed 8 UEM import tasks (7 successful, 1 skipped)
2018-01-16 08:27:13.940 [DEBUG] Processed 89 UEM drive mappings (6 scheduled, 82 skipped, 1 disabled)
2018-01-16 08:27:13.940 [DEBUG] Processed 5 UEM printer mappings (1 scheduled, 4 skipped)
2018-01-16 08:27:13.940 [DEBUG] Processed 15 UEM settings imports (13 successful, 1 skipped, 1 disabled)
2018-01-16 08:27:13.940 [DEBUG] Processed 1 UEM drive hiding setting (1 successful)
2018-01-16 08:27:13.940 [DEBUG] Processed 2 UEM ADMX-based settings (2 successful)
2018-01-16 08:27:13.940 [DEBUG] Processed 131 UEM shortcuts (3 successful, 25 scheduled, 100 skipped, 3 disabled)
2018-01-16 08:27:13.940 [DEBUG] Processed 4 UEM folder redirection settings (2 successful, 2 skipped)
2018-01-16 08:27:13.940 [DEBUG] Processed 1 UEM application blocking setting (1 disabled)
2018-01-16 08:27:14.581 [DEBUG] Started DirectFlex injection
2018-01-16 08:27:14.627 [DEBUG] Launched FlexEngine in DirectFlex mode
2018-01-16 08:27:14.627 [INFO ] Done (35113 ms) [<<IFP#00e843da-3e7]
What are people's thoughts on Direct Flex for the office applications? At the moment I tend to leave this as default, but is there any reason not to enable it on these as well?
Can you post the full FlexEngine.log for this user/session?
Regarding DirectFlex and Office, I think it depends. It is always finding the balance between swift logon and swift application launches. For those applications that are started/closed a lot of times in a session, like Office apps, I import those settings during logon/logoff, rather than importing them at launch/closure of the application (DirectFlex). This means taking the "pain" once during logon and having the benefit of not needing to import/export at application launch/closure for those applications.
+1 on Ivan's request for a full log file. 35 seconds is quite slow, so we should definitely take a look at what's going on.
(And now I'm wondering whether I should try and add timing information to the "Processed N settings" stats dump :-)
One thing that stands out is Windows Explorer.zip
2018-01-16 08:26:55.643 [INFO ] Importing profile archive 'Windows Explorer.zip' (\\domain.com\UEM\UEMProfiles\user.name\Archive\Windows Settings\Windows Explorer.zip) 2018-01-16 08:26:55.830 [DEBUG] ImportRegistry::Import: Calling '"C:\Windows\REGEDIT.EXE" /S "C:\Users\user.name\AppData\Local\Temp\FLXD0E8.tmp"' (RPAL: l=0 (D/E), r=0) 2018-01-16 08:27:02.190 [DEBUG] Read 6 entries from profile archive (size: 1563998; compressed: 130956)
This one alone already takes about 6-7 seconds.
I my current customer's environment, it takes less than a second.
It's a good call - that particular user's Windows Explorer config file is only 129kb compressed, and 1.69mb when extracted, so there is no reason for it to take more than a second to extract / import.
In terms of the infrastructure, the profile server and VDI desktops are both stored in the same geographic location with a full 10GB backbone. Neither the vsphere clusters, profile server, or vdi desktops show any stress or contention from a resource perspective.
For ref, the desktops are W7 linked-clones with 2 vCPU's / 6GB mem and are hosted on a all flash vSAN deployment.
I understand what you say.
What I am not really sure about is how/when decompression is done. Either directly from profile archive location (share) to temp user folder, or is the archive zip first copied over to the local system (user's profile), than decompressed to the temp user folder? Maybe DEMdev can elaborate on that?
Anti-virus can also have huge impact on profile archives. Do you have exclusions in place on both file server and/or VDI for UEM?
User Environment Manager Scan Exclusions
VMware User Environment Manager delivers personalization and centrally managed policy
configurations across virtual, physical, and cloud-based Windows desktop environments. User
Environment Manager allows IT to control which settings users are allowed to personalize, and also maps
environmental settings such as networks and location-specific printers.
On servers, exclude the FlexEngine log path from real-time scans. For example:
On clients, as with other network paths, exclude the following paths from real-time scans:
• VMware User Environment Manager configuration share path
For example: \\server\FlexConfigShare\general
• Profile archive path
For example: \\server\FlexArchiveShare\%username%\Archives
• Profile archive backup path
For example: \\server\FlexArchiveShare\%username%\Backups
Additionally, in nonpersistent desktop pools that have a clean master image, you can exclude these User
Environment Manager executables from real-time scans because they are known to be virus free:
• Flex+ Helpdesk Support Tool.exe
• Flex+ Self-Support.exe
Unfortunately this particular site does use agent based AV in their gold image, rather than offloading it to the hypervisor, so it wouldn't be a stretch to say this could be the overarching reason for sub-par logons.
I've been assured in the past that the necessary exclusions are in place, but I've sent them over again including the ones above, and am just waiting on confirmation. Unfortunately, I don't have access to their AV solution to confirm one way or the other.
In terms of when a config file is decompressed, it was always my assumption that it would be done locally on the desktop - otherwise it would be copying the uncompressed data over the network, which I'd suspect could lead to some serious congestion during peak logon periods.
Again, I concur with Ivan (I usually do :-) – the imports are rather slow. Do you happen to have folder redirection configured?
How long does it take to "manually" unzip that Windows Explorer.zip profile archive that took more than 6 seconds?
Unrelated, but seeing that you're using UEM version 9.0: that will reach its end of general support on 3/17... Upgrading to a later version won't magically solve your perf issues, but just wanted to point this out.
2 people found this helpful
What I am not really sure about is how/when decompression is done. Either directly from profile archive location (share) to temp user folder, or is the archive zip first copied over to the local system (user's profile), than decompressed to the temp user folder?
No, and no, respectively :-)
Maybe UEMdev can elaborate on that?
Certainly! To minimize network traffic and local disk actions, the process is as follows:
- FlexEngine streams the remote profile archive, i.e. reading it in chunks from the first byte to the last and decompressing it on the fly, without any seeks or additional reads. (This is the reason why we have our own "special" ZIP file format: being able to read in such a fire-hose fashion).
- Every file we encounter in the ZIP is written into the actual destination folder, but with a temp name. Once the file has been extracted correctly, it's renamed to its actual file name.
- The only exception is the .REG file; this is written into the user's temp folder and fed to Reg(Edit).exe from there.
1 person found this helpful
This is 99% certain down to anti-virus as already suggested.
I decided to fire up a fresh pool with no anti-virus installed and run a side by side comparison. With no AV it only takes UEM 5.5 seconds to process the entire config, and the desktop is fully usable after 40 seconds. With AV it takes 19seconds for UEM, and the desktop was usable after 70- 77 seconds... pretty massive difference.
As mentioned, I've been assured that the exclusions are in place, but the proof is in the pudding in my eyes. Have gone back with my findings, so it's now back with the site to check.
Thanks for all the help - grand input as usual.
Thanks for the feedback! Glad you narrowed it down to AV.
Has your team ever narrowed down the AV Exclusion issues? I have insane logon times, upwards of 5 minutes +, and it's a night and day difference without AV. Exclusions are in place, but we use Carbon Black Defense, which is a beast to get working right in any environment, so I suspect one of the flex executables' actions are just is not liked well in Carbon Black.