In my previous article I went through the configuration and setup of the FSLogix profile container solution and the Citrix Profile Container solution. I enabled optimizations that are recommended by each and got ready to compare their performance.
Before comparing performance, I first needed to understand how FSLogix and Citrix implement their AppX optimizations, as AppX package installation significantly slows down the logon process. (To learn more about troubleshooting these issues, I’ve included some additional resources at the end of this blog.)
To satisfy this curiosity and technically validate the optimization features, I outlined a structured investigation process. Here are the steps I followed to trace the AppX package handling:
- Setup a Process Monitor trace
- Examine the logs to find timestamps
- Explore other associated data
- Find relevant events and actions
- Exploring the results of enabling the optimization
- New phase of Analyze Logon Duration
- Summary of findings
Setup a Process Monitor trace
To understand the technical nuances of Citrix and FSLogix profile container solutions, I’m going to run a Process Monitor capture and go along with their log files to try and provide some context for what each solution is doing. Specifically, I want to explore the enhancements to increase performance with AppX packages.
To capture the logon information, I’ll use the ControlUp script action “ProcMon – Trace System Activity.”
I defined the Duration to be 200 seconds to ensure that I’ll capture the entire logon process. Process Monitor (procmon.exe) needs to be stored in a folder readable by the machine. In my example, I have procmon.exe within the C:\swinst\sysinternals folder with the process monitor log stored in the D:\ProcMonLogs folder.
It’s important to note that procmon, when run at the system level, captures about 1GB of information per minute (sometimes a bit more, sometimes less, but this seems to be the average).
Once the Procmon script started, I logged into the machine. It’s important to note that I am using profiles that exist, meaning that I’ve logged into a machine previously that created these profiles. The reason why this is important is that a first logon where a profile container needs to be created does slow down the logon process as it has a series of steps required to get the profile container created and ready. Another note for this document is that procmon does increase logon duration but it tends to do so proportionally from a non-procmon monitored logon.
Examine the Logs to Find Timestamps
Examining the FSLogix Profile log file, it time stamps when it finds the “InstallAppXPackages” registry value.
Using the Process Monitor log, I can examine from that timestamp on what FSlogix does after it reads its configuration.
FSLogix, after it reads the “InstallAppXPackages” registry value seems to initialize the Windows.Management.Deployment.PackageManager followed by reading the AppxPackages.xml file.
Explore Other Associated Data
I was curious what is in the contents of the AppXPackages.xml file.
This file contains a list of AppXPackages that were “Previously Installed.”
Find Relevant Events and Actions
From there, FSLogix appears to call the RegisterPackageOptions. At this stage, the service manager has the AppX Service take over to do its initialization thing.
Once the AppX Service is started, FSLogix calls “OnDemandRegisterOperation” for each package listed in the “PreviouslyInstalled” list:
The Details view of the event shows that FSLogix is the caller of this process:
During this time the AppX Service goes through each package and sets a PackageStatus registry value to 2048
Exploring the Results of Enabling the Dptimization
The AppXDeployment event log does show the entire list of AppX packages that “will be installed.”
And the AppReadiness log does show “32 tasks” which is all the install tasks.
And for some AppX packages, they are processed regardless of them being in the list of previously installed packages. This is visible because the event shows the “install succeeded” and tells us how long it took to process the package.
But for other packages we can see that the install task was removed.
With the AppReadiness/Operational log also reporting that the install was cancelled for these packages.
Unfortunately, still processing the 30-ish tasks still takes some time, even if only 7 were processed for installation. However, testing with the optimization disabled also shows the same cancelled events for the same packages.
New Phase to Analyze Logon Duration
With the new events I can add an FSLogix AppX Package Preparation phase to the Analyze Logon Duration.
These were the packages processed with the optimization enabled or disabled.
Summary of Findings
I tried to measure results on a Windows Server 2022 and Windows 11 24H2 multi-session machine and I was unable to see any time savings. However, I have done the “optimization” of removing as many AppX packages from both operating systems. I’m unsure if the FSLogix AppX optimizations apply only to the packages that I removed but I was unable to measure any improvement—and the FSLogix AppX Package preparation phase takes some time so it does add a little time to the logon!
I’m presenting these findings for what I’ve discovered as they are. I was hopeful to see an improvement, but sadly I don’t. Microsoft doesn’t explain how this setting actually operates and how you could expect to see results. I’ve found other people who have attempted to validate the functionality of this feature but it appears they did not have much luck either. This Microsoft support article appears to have a PowerShell snippet that implies what FSLogix is doing during logon, but it’s effectiveness, I suppose, is questionable.
Stay tuned to see if Citrix User Profile Container does better!
Additional Resources
- 5 Key Updates to ControlUp Analyze Logon Duration, Part 2: AppX Package Load Times
- Troubleshooting AppX Load Packages in ControlUp
- ControlUp Analyze Logon Duration After Hours: An Extended Webinar Q&A
- Tips for Decreasing Logon Time on Windows Devices
