ControlUp Analyze Logon Duration After Hours: An Extended Webinar Q&A

Recently, Joel Stocker, our Sr. Director of Product Marketing, and Trentent Tye, our resident Slayer of Slow Logons hosted a deep-dive webinar on our Analyze Logon Duration (ALD) script and they got so many questions that they couldn’t answer them all in real time. So, just for you, tech friends, they did an extended Q&A where they answered all of the questions they couldn’t get to during the event. And if you’ve still got questions after watching this, you can  hit us up on Twitter @ControlUp.

Take it away, Joel and Trentent!

Q: Our “AppX: Load Packages” stage is taking a long time, over 35 seconds, how do we bring this number down?

A: The easiest optimization opportunities can be found in our recent blog about AppX Package Load Times. The biggest one is enabling the policy to disable the “Show first sign-in animation.” Once you do that, you can save probably seven to ten seconds right off the bat. Beyond that, removing as many AppX packages as possible or potentially making sure that you don’t have other processes running while a logon is occurring. One example, App Volumes will actually attach App Volumes to the logon at the same time as the AppX packages are loading, which causes contention. And if you don’t have enough virtual CPUs or CPU capacity, it slows logons down.

Within the article, I specify other things you can try. But, full disclosure: it’s probably completely unsupported by Microsoft.

Q: Is there a good list available of which AppX packages should NOT be removed?

A: I don’t believe so. And that’s because the list of AppX packages changes with every operating system, Microsoft adds more into each version of the operating system. One thing I can say is that if you use the long-term servicing channel versions of Windows 10, they actually come with a lot of AppX packages removed by default. If you can use that, you’ll find that you’re probably as optimized as you can be, and a lot of the AppX packages will not be present.

Q: What are examples of the category “Logon Duration: Other”

A: That’s anything that resides outside of the phases that the ControlUp console captures. So, anything outside of group policy or user policy processing will get captured into the “Logon Duration: Other” phase. An example that’s easy to highlight is if you have printer connections where you set your delivery group in Citrix to be delayed until the printer is connected. That will be grouped into “Logon Duration: Other,” but will be visible within Analyze Logon Duration. You can find more information about the different stages presented in the ControlUp Console, Solve and Insights in this KB article.

Q: I assume the Analyze Logon Duration script can only be used within ControlUp? Also, is there anything custom developed with regards to the Analyze Logon Duration script or is everything available via Windows?

A: No, all of our PowerShell scripts are community-driven solutions. What we offer as a value-add is the simplicity of being able to run them. ControlUp, with its scripting engine, can pass parameters automatically to scripts, and you can specify which one of the columns or parameters you want to pass on. Running Analyze Logon Duration within ControlUp is by far the easiest way of running it, but you can certainly run it outside of it. You just need to fill in all the proper parameters, and those parameters are listed within the script along with examples, I believe, so it’s not too difficult to run as just a manual process, but ControlUp makes it two clicks.

Additionally, with ControlUp Automate, we can automatically run the script based off a trigger (e.g., if a certain metric threshold is passed). That way, I can automatically run the Analyze Logon Duration script if, let’s say, the total logon duration metrics is over 30 seconds, and have the output send to me by email or even into a third party tools, like we describe in this blog post.

We also provide support if it’s being run outside of the ControlUp console and you have problems, whether it’s error messages or warnings that you’re getting when you’re running the script. You can always reach out to our support@controlup.com and our professional services team can help you set that up or help you with the requirements or troubleshoot gaps in time that you have within your environment.

For the second part of the question: everything in the Analyze Logon Duration script is public. There’s nothing proprietary. And we’re completely transparent. The script and the source code is available, either on our GitHub or in the ControlUp Script Library, so you can review it and make sure you know it’s operating the way that you would expect.

Q: What might be the cause of the Analyze Logon Duration script not showing the pre-logon metrics (the time between clicking the icon and the ICA file download)?

A: One of the challenges we have is that we can only display what we have data for and for the pre-logon phases, especially with regard to Citrix (we’re pulling that data essentially from the delivery broker). It’s not actually coming from the broker… but it kind of is. It’s a little bit complex. When you log in with Citrix, once you get to the server, it will store any values that are on the broker for that connection in WMI. And so, we’re querying the WMI to pull that information. But if it’s not there because the broker hasn’t supplied that information, or potentially because your client doesn’t have it, because it’s old, it won’t be present. So unfortunately, I don’t know, and I don’t have that answer as to why it’s there sometimes and sometimes not because Citrix is a black box. I don’t have access to their source code to be able to determine that.

Q: Do you track ProfileUnity metrics in the Analyze Logon Duration script?

A: Not at this time. When it comes to the Analyze Logon Duration script, we’re only as good as the technology we’re aware of. Unlike ControlUp, where you can download our solution without any hassle, some of our competitors make it difficult, so we don’t always have access to the software required to build additional integrations for the ALD script. We rely on our customers to say, “Hey, we have this problem, we have this gap in time. We would like some help in analyzing it.” And then we bring in our professional services team so we can explore and understand. That’s what gives us the ability to add those markers, the start and end markers for what a phase is and to add to the ALD script.

If you would like ProfileUnity to be monitored, feel free to reach out to us and we’ll set up some sessions and start looking into what we can do.

Q: We’re having a random issue with some of our Citrix Windows 10 VDI logons. Usually, the logon takes about 30-45 seconds, however, we have seen a logon sometimes take 9 minutes. When we run the Analyze Logon Duration script, the bottleneck seems to occur at the Shell / Active Setup phase. is there a way to dig down into this?

A: A lot of things can block logons. There is a good article by Helge Klein about how Active Setup works, where he explains that you can actually create a custom active setup where it just opens notepad, but it won’t continue the logon process until you close notepad.

There are some customers that I’ve worked with who have actually used active setup to prompt using a custom PowerShell script that shows a window which has a license agreement for a user that they need to accept, as opposed to using the log on banner keys that Windows has built in natively. That could cause a long active setup phase, if it’s being delayed, waiting for some activity to complete.

In reality, how we measure the shell phase is as soon as Explorer.exe starts, that’s when we consider the shell phase to begin. Once the start menu is built, we tie into the built-in Windows events that are only accessible through APIs. Once the start menu says, “Hey, I’m ready, the desktop is ready.” that’s when we consider the phase complete. Anything that happens in between there, you need to do investigation on from the start to the end phase, but that’s how we track it. So, if you’re seeing it being nine minutes, then potentially it’s because Explorer hasn’t completed and we haven’t gotten that event until nine minutes after. Why that could be, requires some more troubleshooting.

Q: Is the pre-logon stage in the Analyze Logon Duration script compatible with RDS RemoteApps?

A: The pre-logon phase for both VMware Horizon and Citrix is because, we’re pulling that data from some data sources that they’re providing. I’m not aware of any pre-logon metrics that Microsoft might be providing, but if you think you have some ideas, feel free to reach out to me and I can do some investigation on it.

Q: Is there a way to dig into specific logon components that take extended periods of time?

A: It’s your environment, so I assume you have the rights to do a lot of things within it. I’m a big proponent of using process monitor to track events and try to understand what’s actually going on. Using process monitor, you can track registry reads and writes, files reads and writes, and even the process stack so you can see where individual processes are consuming a lot of their time. I had a session with XenAppBlog (which you can check out below) about a year ago where I dug into how to use process monitor to try to track phases that way.

Q: When there is an update to the script, is it automatically updated, or do we need to re-download if we have it already?

A: No, it’s not automatically updated, it requires user intervention. When you go to the script actions button within the ControlUp console, the script action will actually have a little update button on it and you can click it there to update the script

Q: Does this work best for new sessions and not sessions that have been disconnected and reconnected numerous times?

A: That’s correct. The Analyze Logon Duration script predominantly will only work for a new session, so any sessions that are disconnected or re-connected will fail (or most likely fail). The reason for that is that we’re using APIs to track when a session was logged on and a reconnection counts as a new log on. When we use that timer to find the events that are associated with it—obviously with a reconnection—we’ll be missing a lot of data. The Analyze Logon Duration script certainly works best on new sessions. When you run the script against a disconnected or re-connected session, generally, you just don’t have any data or you’ll get some warnings at the bottom of the console output.

If a session is disconnected, the ALD script will not run because required parameters aren’t present. For example, we require the client name so we can check to see if there are any printers attached and potentially some other work within that requires the client name. Obviously, the client name doesn’t exist if the session is disconnected, so Analyze Logon Duration will not work for sessions that are disconnected, only sessions that are active. 99 percent of the time when it tells you there’s the missing argument or the argument is system.string or something like that, it’s because you’re running it against a disconnected session.

Q: We configured the prerequisites, but still no success. We are getting an error that it’s “missing an argument”. What can be causing this?

A: As mentioned in the previous question, it’s likely because you are trying to run the Analyze Logon Duration script against a disconnected session.

Q: How can we drill deeper into the ‘Desktop Load Time’ phase in ControlUp? I don’t see any option to do that or is that where ControlUp has its limits?

A: The Desktop Load Time phase in ControlUp directly matches the Analyze Logon Duration “Shell” phase. So anything within the shell phase is what we break down. That includes the AppX packages, the userinit, if they have an Active Directory logon script or potentially the group policy logon script, those could all reside within the shell phase, which is directly analogous to the desktop load time phase in the ControlUp Console and ControlUp Solve.

Q: In order to collect certain logon details, does ControlUp have any license requirements for VMware Horizon?

A: No, there are no special license requirements for either VMware Horizon or Citrix Virtual Apps & Desktops.

Q: Is RSoP logging enabled by default?

A: It is. Microsoft sets that to enabled by default across all their operating systems, whether it be server or desktop OS. The design of it was to log data to the WMI repository, which is a double-edged sword. Because the more data you store in there, the slower WMI becomes.

Learn more: 5 Key Updates to ControlUp Analyze Logon Duration, Part 3: RSoP Logging

Q: Can you comment on why the ControlUp logon metrics vary so much from what we see in Citrix Director? Just trying to understand what ControlUp is monitoring during the logon phases that varies so much from Citrix’s method.

A: The reason they differ so much is that we’re using the native Windows metrics as much as possible, whereas Citrix Director is actually pulling its metrics from the Citrix services that generate events. So the reason it varies so much is that Citrix has its own proprietary method of measuring its stuff, and we don’t have visibility into that. So we’re relying on tried and true and consistent windows built in metrics.

Q: Can you provide more details for what is included in “Windows Pre-Shell (Userinit)”?

A: Within Windows itself, there’s a registry path for the userinit, where it can execute some scripts. And usually it executes like a little batch file and then the userinit does some more activity and you can add things into it if you want to. And I know I have in the past; Microsoft used to have guidance on disabling scripts being run from userinit. But essentially that’s what it is. It’s the userinit that’s executed from whatever processes that are there, and then we track those process start and end times. And then that’s what we report back. It’s essentially anything in that userinit key, the start and the end, and we report how long that process took.

Q: Can ControlUp give the same logon duration details for Linux VDAs?

A: The Analyze Logon Duration script is relying exclusively on the Windows operating system and Windows operating system technology. As of today, we do not track log on details for Linux VDAs. As with anything, because we have script actions, you can extend it to do anything but for Analyze Logon Duration out of the box, it does not give you details for Linux VDAs.

In the Real-Time Console and in Solve, you will be able to see certain metrics from Linux workloads. Things like CPU, memory, disk utilization, and more. We can also tie in with our Edge DX product that has Linux Agents.

Q: The Analyze Logon Duration script routinely shows 6–7 seconds for “Local Group Policy” and it’s showing as being from Citrix Group Policy. Would this potentially be Citrix Policies configured from Citrix Studio or, perhaps, WEM settings?

A: This is an area that will require further troubleshooting and investigation. This, again, might be related to the WMI, if you’ve got WMI filters attached. But again, local group policy shouldn’t have that. Feel free to reach out to us if you have questions about this.

Q: Citrix App Layering would be a good add to your supported technologies list. We use that in our VMware Horizon environment.

A: Similar as the answer for ProfileUnity above: it’s possible to add, but it depends on finding a customer that has issues during that stage of the logon. The customers we’ve worked with that use Citrix App Layering don’t see any negative impact on their logon times or they haven’t asked us to investigate. If you think App Layering is causing some logon delays in your environment, feel free to reach out to us at ControlUp and we can hop on a call with you and start some investigation. We’ll need an environment with these technologies configured and operating so we can better understand the whole picture.

Q: I’m getting the error message “Auditing of “Process Creation” is not set to at least “Success” as required, it is set to “None.” What does this mean?

A: It means exactly what it says. The auditing of process creation is not set to success; it’s set to none. This means as processes are being created, they’re not being recorded in the security event log. We require process start and termination so we can measure how long processes run. That gives us an idea for how long certain phases run. If you’re getting that, you probably don’t have the prerequisites set up entirely. This KB article goes into more detail on the prerequisites.

There’s also a script in our library—Enable requirements for Logon Duration Analysis—that could be of use, although it hasn’t been updated to support all the latest features added into the Analyze Logon Duration script. But the basics are in there.

ALD will do its best to try to show you the data that it can with the information that it has available, but it’s most effective when it has all information available and process start and termination events are a pretty critical one.

Q: Is Citrix Profile Management monitored by the Analyze Logon Duration script?

A: Yes, we track Citrix Profile Management as a whole, but we don’t break it down in detailed stages at this time.

Q: We require that all PowerShell scripts reside in a specific folder in order to run. Is it possible to change the location of where the scripts are stored on the client device for execution?

A: The location where the script is saved (and run) depends mainly on the “Security Context” when running a script action.

If you use “Default (Local System)” the location is: the System account AppData folder (e.g., C:\Windows\System32\config\systemprofile\AppData\Roaming\ControlUp\Scripts)

If you do “Prompt upon execution” or “Shared Credentials” it will use %ProgramData%\Smart-X\ControlUp\Scripts. For this option there is a way to override the location through the registry by adding a String value under HKEY_LOCAL_MACHINE\Software\Smart-X\ControlUp\ with the name SBATempFolder and the value being the location

The only caveat I have for the latter option is you might need to make sure the permissions are available for both users and the machine level when you set that key.

And there you have it: everything you ever wanted to know about ControlUp’s logon duration analysis! If you enjoyed this, subscribe to the ControlUp blog so you never miss any great technical updates.