VMware Horizon Community
dsmproject
Contributor
Contributor

Windows 10 1809, DEM 9.9 - PM to DEM Migration issues and Chrome Archive issue/bloat

We are attempting to migrate from Windows 7 and Persona Management profiles to Windows 10 and DEM.  This is our first look/configuration of DEM, so I feel very much uninformed.

VMware Knowledge Base  This is the guide I am using to attempt migration.  I enabled this on two of my pools to run side by side Persona on Windows 7.  Since go, I have heard nothing but complaints from users that all functions/logins are slow.  Doing this did build DEM profiles for users, but left a LOT of them not fully formed - .tmp files created instead of zips.  My DEM configuration is MAINLY built from defaults and some imported from My Vmware config templates.

The log snippet below is from a user who is still on Windows 7 and running DEM side by side to prepare migration - the log just "dies".  I do not see any reason why the log file stopped logging, but it did not stop cleanly (see end of the last line).  This is not the only profile I have seen this with.  I went through and found a bunch of users archives that had .tmp files and saw this same behavior.

2019-12-19 08:48:03.040 [DEBUG] Conditions: Check for OS Windows 10 = false (Running on Windows 7)

2019-12-19 08:48:03.040 [INFO ] Skipping import for config file '\\srv-fs03\DEM_Config\General\Windows Settings\Default Apps and FTAs.INI' due to conditions

2019-12-19 08:48:03.055 [INFO ] Importing profile archive 'Desktop Shortcuts.zip' (\\srv-fs03\DEM_Profiles\bbadillo\Archives\Windows Settings\Desktop Shortcuts.zip)

2019-12-19 08:48:03.149 [DEBUG] Read 8 entries from profile archive (size: 9767; compressed: 3449; took 65 ms; largest file: 2862 bytes; slowest import took 0 ms)

2019-12-19 08:48:03.165 [INFO ] Importing profile archive 'IE Passwords.zip' (\\srv-fs03\DEM_Profiles\bbadillo\Archives\Windows Settings\IE Passwords.zip)

2019-12-19 08:48:03.914 [DEBUG] ImportRegistry::Import: Calling '"C:\Windows\REGEDIT.EXE" /S "C:\Users\bbadillo\AppData\Local\Temp\FLXF390.tmp"' (RPAL: l=0 (D/E), r=0)

2019-12-19 08:48:05.240 [DEBUG] Read 298 entries from profile archive (size: 223546; compressed: 207106; took 1324 ms; largest file: 8950 bytes; slowest import took 11 ms; registry took 71 ms)

2019-12-19 08:48:05.255 [INFO ] Skipping disabled config file '\\srv-fs03\DEM_Config\General\Windows Settings\IE WebCache.INI'

2019-12-19 08:48:05.271 [INFO ] Importing profile archive 'Internet Explorer.zip' (\\srv-fs03\DEM_Profiles\bbadillo\Archives\Windows Settings\Internet Explorer.zip)

2019-12-19 08:48:06.534 [DEBUG] ImportRegistry::Import: Calling '"C:\Windows\REGEDIT.EXE" /S "C:\Users\bbadillo\AppData\Local\Temp\FLXFEF7.tmp"' (RPAL

This is a log from another user who on log out ended up with an application archive of Chrome as just a .tmp file.  If you look at the last two lines you can see the two different days.  The process again did not finish and I see no reason why?  It does not appear to cut off of a word, however I imagine there are more steps missed.

2019-12-18 14:54:45.456 [INFO ] Exporting profile using config file 'Google Chrome.ini' (\\srv-fs03\DEM_Config\General\Applications\Google Chrome.ini)

2019-12-18 14:54:45.460 [INFO ] Exporting Registry information

2019-12-18 14:54:45.460 [DEBUG] ExportRegistry: Exporting tree 'HKCU\Software\Google\Chrome'

2019-12-18 14:54:45.461 [INFO ] Exported Registry information successfully

2019-12-18 14:54:45.461 [INFO ] Exporting file information

2019-12-18 14:54:45.461 [DEBUG] ExcludeFolderTrees: Adding exclusion for '<LocalAppData>\Google\Chrome\User Data\Default\Application Cache'

2019-12-18 14:54:45.462 [DEBUG] ExcludeFolderTrees: Adding exclusion for '<LocalAppData>2019-12-19 05:16:27.935 [INFO ] Starting FlexEngine v9.9.0.905 [IFP#02ff3c32-3e7>>]

2019-12-19 05:16:27.935 [INFO ] Running as Group Policy client-side extension

The basic setup of DEM is very easy, however, tweaking it to the full experience our users are currently used to is very daunting.

One of the biggest hurdles I have seen is in relation to the way Google Chrome operates in DEM.  Firstly, I could not get any profile archive for Chrome created when using Direct Flex - same with Firefox actually.  If I set them to both to process during log off/log on, I am able to capture them with DEM.  I have seen Chrome archives anywhere from 30mb to 172mb using the below settings.  The ini file for Chrome is listed below.

Google Chrome.ini

[IncludeRegistryTrees]

HKCU\Software\Google\Chrome

[IncludeFolderTrees]

<LocalAppData>\Google\Chrome

[ExcludeFolderTrees]

<LocalAppData>\Google\Chrome\User Data\Default\Application Cache

<LocalAppData>\Google\Chrome\User Data\Default\Cache

<LocalAppData>\Google\Chrome\User Data\Default\Local Storage

<LocalAppData>\Google\Chrome\User Data\Default\Media Cache

[ExcludeFiles]

*.tmp

I had one of my test users login this morning on a new pool - Windows 10 1809, Horizon 7.10, DEM 9.9.  His DEM profile was built while logged into a Windows 7 pool with both Persona and DEM installed.  He mentioned his initial login to Windows 10 was very slow.  I had him log off and back on and actually clock it.  It was almost 6 minutes until he saw the desktop.  The time duration according to the FlexEngine log was just over 2 minutes.  I would imagine that means the other 3 minutes was processing Windows profile creation.  The current setup is using local profiles - we have not yet tested mandatory profiles.

Any help/pointers would be much appreciated.  We unfortunately started this process late, and the time is ticking.  I have opened a support request on our issues and have asked to speak with our VMware rep tomorrow to possibly get some professional services to assist us.

I just started reading about FSLogix profiles and those are starting to sound REALLY interesting.

Thanks all!

Tags (1)
5 Replies
dsmproject
Contributor
Contributor

Just for tracking purposes - I upgraded to DEM 9.10 and re-downloaded the Google Chrome application profile with DirectFlex enabled - it now works.

I tested Mozilla Firefox, again with re-downloaded the profile, and that does not work.

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi dsmproject,

Sorry to hear that you're running into strange issues. I don't know much (or, well, anything...) about Persona Management, but let me at least respond to some of the things you mention.

When the DEM agent creates a profile archive (that is, the zip file with the settings, as "instructed" by the Flex config file), it stores it as a .tmp file in the user's profile archive folder. Once the export for that particular Flex config file has completed successfully, that .tmp file will be renamed to its final .zip extension (so as not to overwrite a previously created profile archive with an incomplete one in case an error occurs.)

If you see .tmp files in your users' profile archive folders, that is an indication that either the export was interrupted or crashed, or that the final rename from .tmp to .zip failed for some reason. The latter should be clearly visible in the log, so I guess it's the former, as that's also what that log fragment you provided is pointing to:

2019-12-18 14:54:45.462 [DEBUG] ExcludeFolderTrees: Adding exclusion for '<LocalAppData>2019-12-19 05:16:27.935 [INFO ] Starting FlexEngine v9.9.0.905 [IFP#02ff3c32-3e7>>]

As for your "It does not appear to cut off of a word, however I imagine there are more steps missed." with regard to this log line: individual log lines are not written to disk immediately, but they are written to an in-memory buffer of a few kilobytes and only flushed to disk when that buffer is full. So, most probably a few more lines were logged after that "Adding exclusion" one; they just did not make it to disk before the export was terminated.

Is there anything in your environment that might be limiting how long logoff scripts can run?

I had one of my test users login this morning on a new pool - Windows 10 1809, Horizon 7.10, DEM 9.9.  His DEM profile was built while logged into a Windows 7 pool with both Persona and DEM installed.  He mentioned his initial login to Windows 10 was very slow.  I had him log off and back on and actually clock it.  It was almost 6 minutes until he saw the desktop.  The time duration according to the FlexEngine log was just over 2 minutes.  I would imagine that means the other 3 minutes was processing Windows profile creation.  The current setup is using local profiles - we have not yet tested mandatory profiles.

Are you familiar with the Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop guide? That should hopefully speed up profile creation. Also, as indicated in that guide: mandatory profiles don't work reliably with Windows 10 Version 1809 or later.

dsmproject
Contributor
Contributor

DEMdev,

Thank you for the reply!

Is there anything in your environment that might be limiting how long logoff scripts can run?

Not that I am aware of.  I went through my other group policies, we have a bunch, and did not see anything.  Do you know of any policy/setting that has that ability?  We are on Horizon agent 7.10, if that matters.  I would imagine what you are asking is a Windows function.

Are you familiar with the Creating an Optimized Windows Image for a VMware Horizon Virtual Desktop guide? That should hopefully speed up profile creation. Also, as indicated in that guide: mandatory profiles don't work reliably with Windows 10 Version 1809 or later.

I was not originally, so my previous login numbers were based on a previously built Windows 10 image (optimized by us, but not using the guide).  I sent the guide to my tech who does all of the imaging, and he built a new image/pool using that guide.

When using that new parent image logging into the new pool with no previous DEM profile, the login took just over 4 minutes.  The DEM profile creation was about 7 seconds, the rest of that time was "preparing Windows".  Subsequent logins took up to over 5 minutes, again the MAJORITY of time spent on "preparing Windows".

I have a support request with VMware 19089697012 on this issue.  Unsure what your involvement level with VMware Tech support is, but I have uploaded additional logs to that ticket.  I have also reached out to a vendor to assist us optimizing this process.

The other thing I have started looking into is FSlogix.  I found multiple posts on forums talking about profile issues, and seems to be a popular marriage - VMware DEM and FSlogix.

Thoughts?

Reply
0 Kudos
DEMdev
VMware Employee
VMware Employee

Hi dsmproject,

I went through my other group policies, we have a bunch, and did not see anything.  Do you know of any policy/setting that has that ability?

I'm only aware of the System | Scripts | Specify maximum wait time for Group Policy scripts computer policy setting, but we actually check that in the DEM agent and log a message about it if it's different from its default of 600 seconds, so I guess you would have seen that in your logs.

I was just wondering whether there might be something else in your environment that might be affecting this.

Are these persistent desktops where you're encountering the problem? If so, anything in the Windows event log about crashes or terminated logoff scripts?

the login took just over 4 minutes.  The DEM profile creation was about 7 seconds

Just to make sure I understand "DEM profile creation" correctly: you mean that DEM's logon processing took 7 seconds? That is, the log fragment that starts with [INFO ] Performing path-based import ended with [INFO ] Done (about 7000 ms)? In that case I'm afraid I won't be of much help in speeding up your logons, as that sounds pretty good (depending on what exactly you have configured in DEM, but still.)

I quickly browsed through the conversation you have/had with VMware support, but unfortunately I cannot access any files attached to support tickets.

As for FSLogix, that is definitely on our radar. Our EUC technical marketing team recently published a tutorial about integrating FSLogix Profile Containers and DEM (as part of the larger Just-in-Time Management Platform (JMP) product bundle.)

dsmproject
Contributor
Contributor

Are these persistent desktops where you're encountering the problem? If so, anything in the Windows event log about crashes or terminated logoff scripts?

We are only dealing with Link Clone pools with profile management.  I will attempt to find a user who had consistent logoff failures and target them.

Just to make sure I understand "DEM profile creation" correctly: you mean that DEM's logon processing took 7 seconds? That is, the log fragment that starts with [INFO ] Performing path-based import ended with [INFO ] Done (about 7000 ms)? In that case I'm afraid I won't be of much help in speeding up your logons, as that sounds pretty good (depending on what exactly you have configured in DEM, but still.)

Yea, the time did grow the more I was playing with the profile and customizing, however it was all under 1 minute.

I quickly browsed through the conversation you have/had with VMware support, but unfortunately I cannot access any files attached to support tickets.

No worries, thanks for looking.  As you stated, the speed issue is not DEM related.  Obviously the frustration is with the Windows login times, which is unfortunately part of this "solution" for profiles.

Thanks,