Co-authored by Pim van de Vis, Product Engineer, User Environment Manager, Research & Development, VMware
In Part 1 of this blog series, you were introduced to the VMware User Environment Manager Application Profiler. In Part 2, VLC Media Player was profiled, predefined settings were applied, and you were introduced to a few Application Profiler best practices and troubleshooting techniques. In Part 3 we use Google Chrome to demonstrate Application Profiler exclusions, including when, why, and how to use them.
Introduction to Exclusions with Application Profiler
Windows applications tend to write registry and file system data in a variety of locations. A portion of the data is relevant to persisting the user experience from session to session, and that of course is what we are interested in when profiling an application to provide personalization. Most applications also create files we may not want to persist, such as temp, log, and crash dump files. Depending on the application and how it is used, these files may quickly grow in size, negatively impacting the user experience.
The VMware User Environment Manager Application Profiler includes a number of built-in exclusions for both the registry and the file system. In most cases these defaults suffice, and applications profile quite easily. There are, however, applications such as Chrome that write user-specific configuration data to locations that are excluded by default. In this blog post you will see which locations are excluded by default, how to make exceptions when needed, and how to create your own exclusions to keep user profile archives small.
It is worth mentioning that you can download a custom Flex configuration template already optimized for Chrome from the Community Forum, along with a variety of other templates. The rest of this blog post is aimed at showing the logic and process to create a configuration file for Chrome.
Environment
Installing Application Profiler and performing the initial profiling process is outside the scope of this blog post, and is well-documented in the VMware User Environment Manager Application Profiler Administration Guide. This blog post focuses on the advanced scenario of troubleshooting and customizing a profiled application using exclusions.
The following describes the configuration used to profile Chrome. For a comprehensive list of supported operating systems for Application Profiler, see the VMware User Environment Manager Application Profiler Administration Guide.
Application Packaging and Profiling Machine Configuration (Profiling VM)
The application packaging and profiling machine (also called the profiling VM) is configured with the following:
- Windows 10 Anniversary Update (AU) VM.
- VMware App Volumes Agent version 2.12.
- VMware User Environment Manager Application Profiler version 9.1.
- svc-profiler domain account has local administrative privileges.
The App Volumes Agent is an optional component, and is part of the VMware End-User-Computing JMP solution. This agent is included so the same VM can be used to build an App Volumes AppStack for application deployment, and to profile the application for personalization with User Environment Manager. If you would like to learn more, or include App Volumes in your environment, refer to the App Volumes Reviewer’s Guide.
End-User Machine Configuration
The end-user machine in this example has the following configuration:
- Windows 10 AU instant-clone VM.
- VMware App Volumes Agent version 2.12.
- VMware User Environment Manager FlexEngine version 9.1.
- jspencer is a standard end user domain account.
Application Profiling with User Environment Manager
Google Chrome version 57.0.2987.133 was captured to an App Volumes AppStack using all default installation options. The AppStack was then used to deliver Chrome to the profiling VM.
The following steps are taken during the User Environment Manager application profiling process:
- Launch Chrome.
- Browse to vmware.com and create a bookmark for the site.
- Configure Chrome to display the bookmarks bar.
- Stop (close) Chrome.
At this point we would expect the Application Profiler to detect Chrome being stopped, and prompt us to complete the profiling process. This is not the case, which is an indication that the Application Profiler still sees one or more running processes related to Chrome. Windows Task Manager does not indicate that Chrome is running, as there are no processes named chrome.exe.
Clicking the Stop Analysis button on the Application Profiler window brings up a list of running child processes from the application (Chrome) being profiled.
Notice there are two unique process IDs (PIDs) for chrome.exe. Yet, we still do not see chrome.exe listed in Windows Task Manager. During the application profiling process, if Application Profiler does not detect the application stop event, the cause is typically related to child processes. Depending on the application, one of two methods for troubleshooting will commonly be used. We look at each of these in the following section.
Analyzing Application Does Not Detect Application Stop
When you stop an application and the Application Profiler does not detect the event, the most common cause is that the primary executable spawned one or more child processes, which are still running. This is often the case when an application creates a Task Bar icon, or continues to run some service in the background of Windows.
When this occurs, click the Stop Analysis button and check the Windows Task Manager to see if there is a match for the process name and PID displayed. If a match is found, attempt to locate the running component and shut it down gracefully. In the case of a Task Bar icon, you might right-click and choose to exit the application. Closing all child processes gracefully (rather than ending the processes via Task Manager) ensures all user data that might be written to the registry or file system completes, and can therefore be properly analyzed by Application Profiler.
Chrome is a somewhat unique application in that it often spawns child processes that do not notify Windows when they close. This results in Application Profiler reporting process names and PIDs that are not detected by Windows Task Manager, as seen in the previous graphic. Because of this, it is necessary to force Application Profiler to stop, even though it indicates the child processes are still running, in order to continue the application profiling process. Doing so has other implications to DirectFlex, which we cover later in this blog post.
For now, we continue with the application profiling process. To do so, the Yes button is clicked on the Analysis Session Is Running window to stop the profiling session, despite the extra chrome.exe processes.
Using File Exclusions with Chrome
Upon completion of the application analysis, we see a single registry tree to be included in the Chrome configuration file.
If we complete the application profiling process and start providing personalization for Chrome with this configuration file, we find bookmarks are not preserved for our end users. This should not be the case, as we specifically created a bookmark during the application profiling process. Additional features in the Application Profiler can be used to determine why this is happening.
Selecting the Manage Exclusions option within Application Profiler brings up a list of default exclusions for the file system or registry.
Clicking the Settings tab and deselecting the Enable File Exclusions check box disables the default file exclusions list in real time, and displays the files and folders that were previously excluded. In this case, the updated Flex Config File output window indicates there were files created or modified in %LocalAppData%\Google. In addition, we see an extensive list of files in %LocalAppData%\Temp (and other locations not displayed in the graphic) that Chrome modified during the profiling process. These files and folders were excluded by the Application Profiler default exclusions, as it is uncommon for applications to write user configuration data to these locations.
Browsing to %LocalAppData% on the local file system of the profiling VM, we can see Chrome created the folder User Data to store a variety of user configuration information.
Chrome essentially creates several databases, and stores inside of them user configuration settings such as bookmarks. Because of this, it is necessary to include %LocalAppData%\Google\Chrome in the Flex configuration file. To do this, the IncludeFolderTrees section is manually added to the original Flex configuration file. Note that Enable File Exclusions has been selected, as we do not want to include all of the files that had been automatically excluded.
Completing the profiling process and using this configuration file to provide personalization for Chrome would properly persist bookmarks and other user configuration settings between sessions. Success!?
Well…sort of. Yes, we fixed the personalization problem, but we have created a new problem that may not be apparent right away.
User Profile Archive Growth
Importing and exporting user profile archive files to provide personalization of applications is a foundational feature of User Environment Manager. These operations can be done at login and logout, or at application start and stop, when using DirectFlex. Application configuration is typically done using registry settings or simple configuration files such as INI or XML. Because these settings require little space on disk, only small amounts of data are being transferred during import and export, resulting in excellent performance for end users.
Chrome uses databases to store its user configuration data, and these databases can grow very quickly. As an example, browsing with Chrome for less than two minutes to sites such as YouTube caused my %LocalAppData%\Google\Chrome\User Data folder to grow to 16 MB. It is common for this directory to grow to hundreds of megabytes over time, which could impact the performance of user profile archive import and export operations.
Although we do not have the space in this blog post to cover all the testing, we have found that specific directories tend to grow significantly, though they are not really adding value to the personalization process. By creating a few manual exclusions, we can significantly reduce the size of the user profile archives.
One last addition we can make to reduce the size of the user profile archives is to exclude any TMP files. A quick search of %LocalAppData%\Google\Chrome finds a number of these files that will grow over time, but add no value to personalization. Note the wildcard (*) support for exclusions.
With these additions to the Flex configuration file in place, we can now complete the application profiling process. Before we start providing personalization of Chrome to end users, we need to consider how or if DirectFlex will be used with Chrome.
Configuring DirectFlex for Profiled Applications
Application Profiler by default enables DirectFlex for profiled applications. DirectFlex is a feature of the User Environment Manager Agent (FlexEngine), which imports settings when an application is started and exports user customizations when the application is stopped, rather than at login and logout. When an application is stopped, DirectFlex should detect the stop of the application process and any child processes, then proceed with the export.
As seen during profiling, Chrome creates several chrome.exe processes as the application is used. DirectFlex tries to keep track of each process, because the export operation should occur when the last chrome.exe process exits. Because Chrome does not notify Windows of all the child processes it creates, DirectFlex may not accurately detect when Chrome is stopped, as seen during the profiling process. This may prevent the export operation from occurring as intended.
In the case of Chrome, there are two recommended methods to solve this.
DirectFlex Settings for Google Chrome
The first option is to simply disable DirectFlex for Chrome by deselecting the check box in the User Environment Manager console after application profiling is complete. Note the prompt to answer Enable config processing during logon and logoff? when DirectFlex is disabled.
The second option is to continue using DirectFlex to import settings when Chrome is started, but to configure User Environment Manager to export the settings on logout, rather than at application stop. This removes the requirement for DirectFlex to determine when Chrome has been stopped. Again, this configuration is made from the User Environment Manager console post-profiling. Select Export at logoff from the Export moment drop-down menu.
Conclusion
The following is a brief summary of the application profiling concepts and practices covered in this blog post, which you can apply to your own applications.
- When profiling, stopping or closing the application should automatically cause the Application Profiler to complete the analysis phase. If this does not occur, it is an indication that the application has one or more child processes that are still running.
- If child processes are left running after the application is stopped, the most likely cause is a Task Bar icon or background service. Use the Task Manager to determine whether Windows sees application processes, and attempt to gracefully stop them.
- Default exclusions work for profiling most applications. Toggle exclusions on and off from the Application Profiler to determine if your application is writing information in one of the excluded locations.
- User profile archives are typically small (less than 1 MB), which is important for providing a good user experience during import and export operations. Watch for archives that grow quickly or very large, as they may be storing unnecessary files.
- Use manual exclusions to prevent storing unnecessary files and folders in user profile archives. Specifically, watch for large files, and files or folders with names or extensions such as TMP, LOG, CACHE, and so on.
- For additional detail on exclusions, see the VMware User Environment Manager Application Profiler Administration Guide.
