VMware Logon Monitor
When rolling out a VDI solution (or really, anything that touches on the user experience), it's crucial to understand how the change might impact the users and to ensure that they are left with a good impression of the solution. They say that first impressions are most lasting, and the first impression that your users are going to see (for most solutions) is logon time. That means that it's crucial that your solution does not negatively impact logon times, as that will color the entire experience. So, how do you accurately measure it?
Well, VMware released a Fling called Logon Monitor (and, it's now baked into the Horizon 7.2 agent). It's a tool that's sole purpose is to measure the logon process and to report on what's happening during a user logon. After it's installed, it logs (with excruciating detail) everything that occurs during a logon, storing the file in a default location of C:\ProgramData\VMware\VMware Logon Monitor\Logs
It creates a file for each logon event, recording information about the desktop system itself (its FQDN, IP, DNS Servers, etc.), as well as information about exactly what the desktop is doing and when it's doing it during the logon (loading the ntuser.dat hive, discovering a local domain controller, processes starting, etc.). It's actually pretty overwhelming, but down at the bottom of the file there's a nice summary that contains all of the information that you're going to need 99% of the time.
At the end of the log file, it records the total logon time, as well as the time that it took the system to accomplish various aspects of the logon (Folder Redirection time, Shell Load Time, User/Machine Policy Application Times, and a few others). This set of data makes testing so much easier, as not only is it a definitive source of timing (no worrying about someone sitting down with a stopwatch and missing some cue), but it breaks out how much time the system spends on each section of its logon. If a given desktop is taking 2 minutes to complete a logon and 115 seconds of that is spent on User Policy processing, you've got a pretty clear indicator of what to look at to improve the logon experience.
If you look at the Fling webpage, you'll notice that there's some documentation that includes configurable settings for Logon Monitor. The two settings that really caught my eye were remoteLogPath and logHistoryPath. The first allows you to send the logs to a remote system, such as a central file share for all of your desktops, and the second one controls the log rotation so that it won't fill up your drive. Unfortunately, there's some caveats with each of those settings.
The one that took me a bit to figure out is that system variables don't quite work the way you might expect with remoteLogPath. Even though it is recording the user's logon and, indeed, names the file after the user who is logging in, the process is actually being executed as the computer account. This means that if you try to send the logs to a file share using syntax like \\server\share\%username% you're going to end up with folders based on computer names, not user names. Its permissions are also based on the computer account, which could cause some issues if the share is locked down.
The logHistoryPath setting works as you'd expect, except with the caveat that it only affects logs that are stored locally. So, if you're pointing your logs at a file server, you're going to need some sort of cleanup process to go through and remove excess files.
Well, VMware released a Fling called Logon Monitor (and, it's now baked into the Horizon 7.2 agent). It's a tool that's sole purpose is to measure the logon process and to report on what's happening during a user logon. After it's installed, it logs (with excruciating detail) everything that occurs during a logon, storing the file in a default location of C:\ProgramData\VMware\VMware Logon Monitor\Logs
It creates a file for each logon event, recording information about the desktop system itself (its FQDN, IP, DNS Servers, etc.), as well as information about exactly what the desktop is doing and when it's doing it during the logon (loading the ntuser.dat hive, discovering a local domain controller, processes starting, etc.). It's actually pretty overwhelming, but down at the bottom of the file there's a nice summary that contains all of the information that you're going to need 99% of the time.
At the end of the log file, it records the total logon time, as well as the time that it took the system to accomplish various aspects of the logon (Folder Redirection time, Shell Load Time, User/Machine Policy Application Times, and a few others). This set of data makes testing so much easier, as not only is it a definitive source of timing (no worrying about someone sitting down with a stopwatch and missing some cue), but it breaks out how much time the system spends on each section of its logon. If a given desktop is taking 2 minutes to complete a logon and 115 seconds of that is spent on User Policy processing, you've got a pretty clear indicator of what to look at to improve the logon experience.
If you look at the Fling webpage, you'll notice that there's some documentation that includes configurable settings for Logon Monitor. The two settings that really caught my eye were remoteLogPath and logHistoryPath. The first allows you to send the logs to a remote system, such as a central file share for all of your desktops, and the second one controls the log rotation so that it won't fill up your drive. Unfortunately, there's some caveats with each of those settings.
The one that took me a bit to figure out is that system variables don't quite work the way you might expect with remoteLogPath. Even though it is recording the user's logon and, indeed, names the file after the user who is logging in, the process is actually being executed as the computer account. This means that if you try to send the logs to a file share using syntax like \\server\share\%username% you're going to end up with folders based on computer names, not user names. Its permissions are also based on the computer account, which could cause some issues if the share is locked down.
The logHistoryPath setting works as you'd expect, except with the caveat that it only affects logs that are stored locally. So, if you're pointing your logs at a file server, you're going to need some sort of cleanup process to go through and remove excess files.
Very cool, thanks for sharing!
ReplyDeleteDid you ever figure out the correct syntax for using the remoteLogPath successfully? I've been banging my head on this one for a month now. The alternative I guess would be to run a post process script of some kind to do it after the fact...
ReplyDeleteI also haven't solved that one, although I haven't been able to focus much time on it. All in all, the remote storage of logs seems a little hinky, as the log rotation doesn't work on such a share. As such, you're kindof stuck with running a scheduled cleanup script anyway, so it could potentially move files into appropriate folders, too.
DeleteI got the remotelogpath running in the past but am not with that customer anymore so can't check. I believe the \ needed to be added in the end + the user that is logging in needs write rights on the share.
DeleteThanks Wouter, but I think you got it flipped. I just tested it and it needs to *not* have a trailing slash to work. When you include a trailing slash, the logs show it attempting to write \\server\share\folder\\file. You are absolutely on point regarding permissions - I just tested it by creating a Deny rule for the computer account and it was able to create the file regardless (the user account had permissions). Another detail that I forgot to mention in the post: LogonMonitor will not create a folder if it doesn't exist, so for these tests I've manually created a set of folders based on username, computername, etc.
DeleteThis still skirts around the core issue of it using the computername instead of the username though (and appending a $ to the end). What I've seen is that if you use %username% it ends up in a folder name %computername%$ (although if you use %computername% then it ends up in a folder that is named just for the computer). That tickles a memory, but I don't quite recall the significance of a computername with a $ appended, but mayhaps I'll have a chance to research it later today.