Diving into the Netlogon Parser (v3.5) for Message Analyzer
Brandon Wilson here again talking to you about the next generation of the Netlogon parser for Message Analyzer, which is available with the installation of Message Analyzer 1.3.1. Some of this is going to sound familiar if you read my blog on the v1.1.4 parser…you’ll also notice the format of this blog is pretty much the same, but there are some additions on how to properly filter when using the parser (for the better, I promise). Before I continue on, if you for some reason can’t move to Message Analyzer 1.3.1, I should also mention that the link at the bottom of this page can be used to download the Netlogon parser v3.5 as well as the “Netlogon View” for the analysis grid so you can implement the changes into Message Analyzer 1.1, 1.2, or 1.3.
This next generation version of the Netlogon parser (v3.5) was developed with significant enhancements to both performance and problem diagnosis/troubleshooting. When I say significant improvements, I mean just that! I would like to take the opportunity to give a shout out to the Message Analyzer product group for all of their assistance with everything from development to sanity checks to blog reviews as well! As with the release of the Netlogon parser v1.1.4, this version is compatible with Message Analyzer 1.3.1, and is backwards compatible with Message Analyzer 1.1, 1.2, and 1.3 (with some caveats that are explained below). Since the test platform for this particular version of the parser was Message Analyzer 1.3.1, we will use that for examples in this blog.
The interface for Message Analyzer 1.3 and 1.3.1 has changed a bit since, and I’ll try to touch on the areas pertinent to the Netlogon parser here, but outside of the GUI changes the pertinent methods for troubleshooting and parsing using the Netlogon parser are the same as we’ve went over in the previous blog posts, however some of the updates include the ability to easily filter out account warnings and problem identification. If you haven’t reviewed the previous blog posts, these are essential reading for proper usage of the Netlogon parser, and you should review the Introduction blog , the Troubleshooting Basics for the Netlogon Parser for Message Analyzer blog, and the New Features in the Netlogon Parser (v1.1.4) for Message Analyzeras pre-requisites, which cover some of the main features and troubleshooting techniques that were available in v1.0.1 (the initial public release) and v1.1.4 of the Netlogon parser.
It would also be a good idea to get a handle on Netlogon error codes from the Quick Reference: Troubleshooting Netlogon Error Codes blog and troubleshooting MaxConcurrentApi issues in the Quick Reference: Troubleshooting, Diagnosing, and Tuning MaxConcurrentApi Issuesblog, both of which can help guide you to proper troubleshooting and root cause analysis for Netlogon related issues.
As I said in my last blog on v1.1.4, I talk about versions a lot when it comes to the Netlogon parser but in reality, as of the date of this post, they are all named Netlogon.config, and the only way for you to truly know the version you have is to open the file and look at the version table at the top. Trust me, I keep that table up to date (if I didn’t, I would lose track of what I’m working on….again)! The previous versions (1.0.1 and 1.1.4) had many features to help you understand and diagnose Netlogon issues (with v1.1.4 having significant advantages). I’ve said it already, but because it excites me for some oddball reason, I can’t stress how significant the updates are in this version.
As with all of our parsers, this is provided as is, however there are a few different feedback mechanisms for you to use (and I DO want to see your feedback). You can use the feedback link/button in Message Analyzer, reach out in the Message Analyzer forum, you can send an email to MANetlogon@microsoft.comwhere you can submit ideas and any problems or buggy behavior you may run across, or of course you can leave a comment here. I highly recommend reaching out through one of the available methods to provide your suggestions for additional detections to add, problems you encounter, etc.
You can also read up more on Message Analyzer itself at https://blogs.technet.com/MessageAnalyzer
In this walkthrough, we will cover the following:
GUI changes in Message Analyzer 1.3 and 1.3.1
Updates and New Detection Features in the Netlogon Parser v3.5
How to update the Netlogon parser manually to v3.5
How to add the new "Netlogon Analysis" grid view
GUI changes in Message Analyzer 1.3 and 1.3.1
The primary UI in Message Analyzer 1.3 and 1.3.1 is much the same as Message Analyzer 1.2. The “Hide Operations” function is, ironically, hidden a bit more and has been renamed to “Show Messages Only”. BUT, with the Netlogon parser v3.5, it becomes unnecessary to use. That’s because in this iteration, very few operations are used. With that being said, here’s a basic view of the GUI before you open any logs:
The “Show Messages Only” option is found in the Tools menu under Windows à Viewpoint. Once you select it, the Viewpoint tab will now appear in the bottom right. As you can see in the below screenshot, all you need to do is click on the Operations dropdown and select “Show Messages Only”.
Updates and New Detection Features in the Netlogon Parser v3.5
As I mentioned, there are numerous new features and updates added to v3.5 of the Netlogon parser. That being said, I also had to remove some functionality unfortunately. We will be adding these features later using another mechanism, so you will get the option back in the future.
Before I show you the guts of the new features, I want to give you an idea of the updates:
1. First, the things we had to remove…
a. It was with a lot of hesitation, and a lot of frustration in trying to work around problems, that I removed the feature for authentication attempts to be brought together by an operation. There was a catch 22 in the function in that, while it worked flawlessly, there are certain backend items that need to be addressed before it can be re-instituted in order to accomplish the expected performance (unrelated to Message Analyzer).
2. No more 100MB log size limitation!
3. Significantly improved performance!
4. Slight changes to the wording for NO_CLIENT_SITE detection
5. Added multiple error code identifications (and provide the meaning of these codes in the summary output)
6. Evaluate inconsistent/unexpected format lines to still provide valid output for errors and account warnings detected
7. Adjusted wording for multiple summary messages
8. Provided an easier method for filtering to identify problems and account “discrepancies”
9. Adjusted summary wording for Netlogon service startup from “SVC STARTUP” to “SERVICE STARTUP”
10. New analysis grid layout added to the “Layout” dropdown for Netlogon Analysis
So, let’s go over the additions in a bit more detail:
1. No more 100MB log size limitation!
a. Previous versions of the Netlogon parser struggled with file sizes beyond 100MB. Although you could run the parser against larger files, doing so meant it was time to put Message Analyzer in the background and fix something else. That is no longer the case!
2. Significantly improved performance!
a. When I say significant, I do mean significant. To give you an idea, on my test machines, what used to take 24 minutes and some change (on my test machines) to parse took just over a minute!
3. Slight changes to the wording for NO_CLIENT_SITE detection
a. This is where your input comes into play! There was a request to add some wording to indicate lines were related to no client site identification being made. Since the no client site detection is still an operation, wording has been added to the summary of each detection to state “no client site detected” in order to simplify spotting these lines when showing messages only and not using operations.
4. Added multiple error code identifications (and provide the meaning of these codes in the summary output)
a. Most error codes added relate to identifying account issues (including helping you hunt down account lockouts) and potential attempts to compromise security (using invalid accounts for instance). However there are also a couple of new error codes added for troubleshooting purposes. Here is a listing of the errors added for this version (this list also includes a few non-error code related detections that have been added):
Status/Return Code |
Technical Meaning |
0xC000006D |
STATUS_LOGON_FAILURE |
0xC002001B |
RPC_NT_CALL_FAILED |
0xC0000072 |
STATUS_ACCOUNT_DISABLED |
0xC0020030 |
RPC_NT_UNKNOWN_AUTHN_SERVICE |
0xC000006F |
STATUS_INVALID_LOGON_HOURS |
0xC0000193 |
STATUS_ACCOUNT_EXPIRED |
0xC0000001 |
STATUS_UNSUCCESSFUL |
0xC000006A |
STATUS_WRONG_PASSWORD |
0xC0000064 |
STATUS_NO_SUCH_USER |
0xC0000071 |
STATUS_PASSWORD_EXPIRED |
0xC0000199 |
STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT |
NeverPing setting detection |
This detects whether or not the NeverPing registry value is set in the Netlogon\Parameters key. In order to make this determination, a service restart must have occurred while Netlogon logging is enabled. |
“error” detection |
Generic parsing for the word “error”. NOTE: This may come up with some false positives due to its generic nature and it is not case sensitive. For instance, if the phrase “ERROR_SUCCESS” was in a line, this would be flagged by this parsing mechanism. All detections flagged by this parsing operation will have a prefix of “DIAGNOSIS:” in the summary wording. |
“failed” detection |
Generic parsing for the word “failed”. NOTE: This may come up with some false positives due to its generic nature and it is not case sensitive. A real example within a Netlogon log would be during service startup when the DnsFailedDeregisterTimeout value is read; although this is NOT a problem indicator, it registers with a “DIAGNOSIS:” prefix in the summary wording because the word “failed” was detected. |
5. Evaluate inconsistent/unexpected format lines to still provide valid output for errors and account warnings detected
a. In previous versions of the parser, the unexpected formats/inconsistent log lines would be brought into an operational grouping together. With this version, we now break out some of the specifics and identify errors within those lines so you don’t miss a beat!
6. Adjusted wording for multiple summary messages
7. Provided an easier method for filtering to identify problems and account “discrepancies”
a. While the old methods of filtering still work, you are now able to filter on “DIAGNOSIS”, “WARNING”, “failure”, “failed”, and “error” to bring back account warnings or problems that have been identified. We’ll talk about that a bit more later on in the blog.
8. Adjusted summary wording for Netlogon service startup from “SVC STARTUP” to “SERVICE STARTUP”
9. New analysis grid layout added to the “Layout” dropdown for Netlogon Analysis
a. Starting with Message Analyzer 1.3.1, the Layouts menu will now contain the “Netlogon Analysis” grid view as shown below in the “How to add the “Netlogon Analysis” grid view” (note that section is for implementing the Netlogon Analysis grid view on Message Analyzer 1.3 and below). The Netlogon Analysis grid view will provide a streamlined analysis grid that contains only the columns needed for reviewing Netlogon logs in order to save you from adjusting columns each time you open a Netlogon log to review!
So now with some of the explanations of the updates out of the way, let’s take a look at the new detections that are available, along with the new view of the new and existing detections. If you need a recap on the other detections not listed in this blog, please review the Introduction blog , Troubleshooting Basics for the Netlogon Parser for Message Analyzer blog, and the New Features in the Netlogon Parser (v1.1.4) for Message Analyzerblog.
First, let’s take a look at the one item that does still perform operational grouping; the detection of NO_CLIENT_SITE entries in the Netlogon log. As I mentioned before, the change made here is only to reflect that no client site was detected in the summary wording. You can of course use this information to determine where you may be missing proper site/subnet assignments within Active Directory, which can lead to slow or failing authentication attempts.
Before we move onto the new items that are included, let’s take a look at the new look in the Netlogon parser v3.5 for the detections that were already available in v1.1.4:
As you can see, the way the information is presented has changed a bit. This is especially true of authentication attempts. The way the look is broken down now, in simplistic terms, is that if an error is detected that is NOT in an authentication (but may be in response to an authentication), then the error is reported back with the reason for the error, and in some cases some potential problem areas to look at. For example, in the first screenshot (2 screenshots above this paragraph), you can see RPC call cancellation detections, along with no logon server available detections, RPC bad stub data, etc. All lines now contain the real text from the log after the meaning of the error/failure identified with the exception of authentication requests, which still provide you a translated view that has now been enhanced to also provide the meaning of the error code within the line.
The key to note here though, is that all of these are preceded with the word “DIAGNOSIS”. This can greatly ease finding problems, because now we can simplify filtering to find all problems, essentially at a glance. We will get more into filtering through the logs later in the blog.
Another thing to note here is the lines that state “ACCOUNT WARNING”. Many of the new additions to the parser have this at the beginning of the lines. Filtering on “WARNING” or “ACCOUNT WARNING” can show you all the authentication problems. This includes possible security or account compromises (attempting to use an invalid username, an invalid password, attacks resulting in account lockouts, etc). An additional account related prefix added to the summary that you can see above is “WRONG PASSWORD”, which is pretty self-explanatory…
For authentication attempts, the format is a tad different as problems do not contain the “DIAGNOSIS” key at the beginning (however filtering on “DIAGNOSIS” should still point you to the account logon failure reasons). Instead, you will be informed that an authentication was entered, and that an authentication failed, along with the reason for the failure, followed by a simplified translation of the authentication attempt. However, there is an exception to this, and that exception is the authentication failures that are due to account issues, which will still contain the “ACCOUNT WARNING” or “WRONG PASSWORD” wording prefix in the summary. This was done in order to filter out account problems or possible security risks in their entirety.
The highlighted frames in this screenshot show a successful authentication with the new look:
A failed authentication will look similar to the highlighted lines below:
So what are you seeing here? As mentioned above, it shows you that the authentication attempt was entered. The next line tells you that there was an authentication failure, and what the error code translation for the error code is. After that is the actual line from the Netlogon log. Notice though how the line is not prefixed by any “DIAGNOSIS” wording. This was done primarily because it seemed easier to read through authentication attempts without the additional wording (not to mention that filtering on “DIAGNOSIS” will bring back these failures anyways).
As far as authentications that come back with a warning regarding the account, this is shown in the highlighted frames below (it is also shown in the screenshot above as well if you were looking closely):
There is one more status I briefly mentioned above, and that is if an authentication attempt is returned with the wrong password. Those returns will be prefixed by the words “WRONG PASSWORD” in order to make them stand out as seen below:
There is also one more change in this version of the Netlogon parser. There is some code to capture inconsistencies/unexpected syntaxes within the Netlogon log which occurs with some versions of the Netlogon.dll binary versions. In previous versions of the Netlogon parser, these lines would be captured and compiled into an operational grouping titled "The lines grouped here are typically not useful for troubleshooting! Please expand grouping for details", which contained all the detected lines. This version of the parser expands significantly on that. Now the parser is coded to go through these lines to identify authentication attempts and to search for indication of any problems in those lines as well. These lines are now reported with a prefix of “LOG INCONSISTENCY”. If an “account warning” (or potential security risk) occurs, the line will be prefixed with “LOG INCONSISTENCY ACCOUNT WARNING”. If a non-account related error is identified, those lines will be prefixed with “LOG INCONSISTENCY DIAGNOSIS”. All of these lines will be moved to the top of analysis grid due to a lack of a timestamp. So, if you are filtering, the same filtering methods discussed above will ALSO bring back these other lines as well.
Here is a screenshot to provide an example of what these lines look like:
Above, I also mentioned a change to the wording for Netlogon service startups. The syntax is still the same, only the wording has changed:
NOTE: The service startup lines is also where the NeverPing status is detected!
Rather than bore you with 9 million more screenshots of examples of the new functionality, I will provide a few screenshots that contain the new detection feature frames highlighted. Hopefully by this point in the blog, you have a decent understanding of how the format has changed, and what to look for. Later in the blog, we will also take a look at more filtering techniques.
In the below screenshot, you can clearly see that we found some log inconsistencies that contain both account warnings as well as problems, as well as lines with expected syntax that contain problems and account warnings. If we look closer at this example, we can see that an unknown authentication service is attempting to authenticate a user, a disabled account is attempting to authenticate, that we have an RPC call failure, a failure to find a logon server, a failure to share SYSVOL, an account lockout, and a couple more RPC errors. Can you spot these issues?? Never mind the fact that the lines are highlighted, the wording is pretty straight forward as to what was identified.
The next few screenshots show both new and existing functionality with the new wording format for the summary:
Oh and before I forget, I did want to show you an example of the “false positive” detection due to the generic filters to look for “failed” or “error” (in this case, “failed”). I admit, it’s somewhat annoying at times, but is pretty easy to identify typically (I’ve only seen the false positive with service startup so far), and the benefit outweighs the false detection risk.
I think that about covers the new features ramp up....
Are you still with me? Asleep? Drooling from boredom yet?? Let’s just assume you’re still awake and have some interest shall we…!
Known issues
Although the parser is significantly improved, there are still a few known issues:
1. Message Analyzer performance
a. There are known issues with using Message Analyzer on single core virtual machines where the CPU can (and will) spike up to 99-100%.
b. Message Analyzer, when used with the Netlogon parser, can have a decent memory footprint. I recommend having at least 4GB of RAM, but as we all know, the more RAM the better!
2. Netlogon parser performance
a. In certain (rare) scenarios, Netlogon parser performance and functionality can be impacted if there are non-contiguous timestamps within the log file being reviewed. Put another way, if you have temporarily enabled Netlogon logging in the past, and then re-enable it later, you may impact performance and functionality due to the differing timestamps.
i. If you experience this situation, you can stop the Netlogon service, delete or rename Netlogon.log, then start the Netlogon service once again to start from scratch with your file. NOTE: For application servers and domain controllers, this will push authentication and requests over to other servers so make sure you don’t do this during production hours!
3. Timestamps (only when used with Message Analyzer 1.1)
a. When using the Netlogon parser v3.5 with Message Analyzer 1.1, the timestamp -UTC time issue that is corrected when the parser is used with Message Analyzer 1.2 and above still exists. You still gain the additional functionality.
4. False positive “DIAGNOSIS” detections due to the generic queries
a. This is a known issue, but the benefit seems to outweigh the risk in ensuring that no stone is left unturned!
Filtering your output
First things first…you need to know what fields are available so you know how to fine tune your filters. My goal here is not to show you every single way to filter, as there are various methods, but to get you started on how to do some simple and more advanced filtering with the Netlogon parser. The syntax in some cases can be changed to simplify even complex filters, but as I said, this is to get you started. As you become more familiar with Message Analyzer, or if you are already familiar with Message Analyzer, then you will learn the ins and outs of filtering even better.
Variable (Typical Filtering Method) |
Explanation |
Msgtype EX: *msgtype == “CRITICAL” EX: *msgtype contains “CRITICAL” |
Contains the type of message being conveyed within the log file such as CRITICAL, MAILSLOT, SESSION, LOGON, PERF, MISC, etc. This will be found in nearly all messages, but isn’t quite as useful for filtering given the other capabilities of the parser. |
RemainingText EX: *RemainingText contains “failed” |
Can contain many variations of text; anything from a complete line from the log, to random portions of the text that aren’t very interesting for troubleshooting and problem analysis. This can be found in nearly all messages, but may be rare to use given the other capabilities of the parser. |
domainName EX: *domainname == “CONTOSO\” EX: *domainName contains “CONTOSO” |
Contains the domain name for the user attempting to authenticate. For null authentication attempts that do not contain a domain name, this variable will be unpopulated. This is useful to use as a filter to trend authentication failures when they are failing to a specific trusted domain. NOTE: When filtering on the domainName value, you must include the backslash “\” character in the filter if using “==”. This is not required if using “contains” in place of “==”. |
userName EX: *userName == “User1” EX: *userName contains “User1” |
Contains the user attempting to authenticate. This is extremely useful to identify any trending patterns for specific users that are failing authentication. |
originMachine EX: *originMachine == “Win7Client22” EX: *originMachine contains “Win7Client22” |
Contains the name of the device the user is attempting to authenticate from (ie; the source machine or device). Note that this value is not always provided (some authentications from 3rd party operating systems for example). This is useful to trend on a specific source device or machine. |
relayMachine EX: *relayMachine == “USEXCHCAS01” EX: *relayMachine contains “USEXCHCAS01” |
Contains the machine that is proxying the authentication on behalf of the user and source machine. This will typically be an application server (Exchange, IIS, SharePoint, SQL, etc) or a domain controller in a trusted domain. This is useful to help trend authentication attempts from a specific application server in order to identify where bottlenecks may be occurring. |
otherText EX: *otherText contains “Package” |
Contains additional text such as flags for authentication (ExFlags), or in the case of non-NTLM authentication, the authentication package being used (ie; Kerberos, Microsoft Unified Security Protocol Provider, etc). This is useful for narrowing out non-NTLM authentication requests. |
errorCode EX: *errorCode == “0x0” EX: *errorCode == “0xC000005E” EX: *errorCode contains “C000005E” |
Contains the error code returned for the authentication attempt. Use “0x0” to identify successful authentications, or use the specific error code to identify specific failed authentication attempts. While you can use this method, it is typically unnecessary due to other methods provided to filter out specific errors as outlined below in this blog. |
Summary EX: *Summary contains “LOCKED OUT” EX: *Summary contains “user1” EX: *Summary contains “SOME-MACHINE” EX: *Summary contains “failure” |
This is a general filtering method provided by Message Analyzer. The Netlogon parser (all versions) exposes the information necessary for all filter areas mentioned above within the summary area. The takeaway regarding this filtering method is that you can use *Summary contains “<any string>” to find nearly all items of interest, however it may provide more information than you are looking for. An example of this would be if there is a user and machine with the same name; filtering on *Summary contains “samename” would bring back all items related to the user and to the machine with the same name of “samename”, which may not be the desired output. |
In this version of the parser, I have put notes directly into the parser to help you with some very basic filtering; but so you don’t have to actually go open the parser. Here is the breakdown for filters related to accounts and potential security risks:
Filter |
What the filter finds |
*Summary contains "WARNING" |
Filters for account issues (expired passwords, disabled account authentication attempts, invalid username, etc.) |
*Summary contains "WRONG" |
Filters "wrong password" authentication attempts |
*Summary contains “LOCKED” |
Filters for account lockout events |
The table above, as mentioned, is only very basic filtering. So if we look at an example of filtering on “WARNING”, this is what we get:
Or if we filter on “WRONG”, this is what we get:
Now, let’s look at filtering a little more deeply. Let’s say we want to filter out account warnings specific to Kerberos PAC validation or Schannel authentication, in which case the username would be “(null)”. We can do that by using a simple filter of: *Summary contains "WARNING" and *Summary contains "(null)"
Alternatively you can adjust that filter to: *Summary contains "WARNING" and *userName contains "(null)"
Here is an example:
And if we wanted to filter this down even further to look only at Kerberos PAC validation account warnings, we could use the filter *Summary contains "WARNING" and *Summary contains "(null)" and *Summary contains "Kerberos". Alternatively, you could use the filter *Summary contains "WARNING" and *userName contains "(null)" and *otherText contains "Kerberos" as seen in the below example:
Here is the breakdown for basic items related to potential problems identified by the parser:
Filter |
What the filter finds |
*Summary contains "DIAGNOSIS" |
Filters for all potential problems found |
*Summary contains "failure" |
Filters authentication failures |
*Summary contains "authentication" (can also use: *Summary contains "SamLogon:") |
Filters all authentication calls |
*Summary contains "failed" |
General query for the term "failed" |
*Summary contains "error" |
General query for the term "error" |
Filtering the output for troubleshooting issues is basically the same as we discussed above for some more basic scenarios. But let’s say we want to dig deeper and review multiple accounts….
Let’s say for instance we want to try to filter out account lockout issues (this could also be tied into the above topic of course) for a user named “user1” or for any Kerberos or Schannel authentication attempts. In that case, I would need to supply some parenthesis around some of the filter, which would result in a filter of:
*Summary contains "WRONG" and (*userName == "user1" or *userName == "(null)") or *Summary contains "LOCKED" and (*Summary contains "user1" or *Summary contains "(null)")
-or you could use-
*Summary contains "WRONG" and (*userName == "user1" or *userName == "(null)") or *Summary contains "LOCKED" and (*userName == "user1" or *userName == "(null)")
What does this filter do you might ask? Well, it looks for the “WRONG” in “WRONG PASSWORD” or it looks for the “LOCKED” in the summary wording of “ACCOUNT LOCKED OUT”, then, in the case of the first filter example, specifies that the words “user1” or “(null)” must be included in the summary as well. In the second example, it’s a bit more refined. It still looks for “WRONG” or “LOCKED” in the summary field, but it then looks specifically at the username variable to see if there are users named “user1” or “(null)” in those fields.
Now, and this is a bit outside of the scope of this blog, keep in mind that in the case of an account lockout, the DC you are looking at may not be the source of the lockout, so it may not contain all (or any) of the wrong password attempts that actually led to the account lockout. In that case, you will need to determine the DC that the account was locked out from and review the Netlogon logs on that DC as well. Here is a simple example:
In this example, you can see 2 wrong password requests for a user named user1 in the child.domain.com domain, followed by an account lockout. If your account lockout threshold is, let’s say 10, then the wrong password must have also been passed to other domain controllers as well, so there may be more hunting to do because this only accounts for 2/10 of the bad attempts.
The bottom line:
For simple filtering where you have known values you are looking for, you can use a simple filter with “and” or “or” separating what you are looking for. But if there are multiple constraints, such as searching for multiple string potentials in the summary, and then narrowing that view only to a specific machine/device (or more than 1) or user, you have to “and” the filter, open parenthesis, put in your additional constraints, then close the parenthesis.
Looking at the previous example provided you can see this syntax:
*Summary contains "WRONG" and (*userName == "user1" or *userName == "(null)") or *Summary contains "LOCKED" and (*userName == "user1" or *userName == "(null)")
Notice in the example there are constraints to look for any summary containing “WRONG”, with the additional constraint that the line also must contain the userName of “user1” or “(null)”, which is then followed by the search for the phrase “LOCKED” with the same userName constraints. You have to be specific!
Now, let’s look at the same example, but this time let’s say I don’t want to include the “(null)” user account, but I do want to see all other locked out accounts. For this, we use a syntax like this:
*Summary contains "WRONG" and (not *userName == "(null)") or *Summary contains "LOCKED" and (not *userName == "(null)")
-or-
*Summary contains "WRONG" and (not *userName contains "(null)") or *Summary contains "LOCKED" and (not *userName contains "(null)")
-or-
*Summary contains "WRONG" and (not *Summary contains "(null)") or *Summary contains "LOCKED" and (not *Summary contains "(null)")
A lot of options there, right! The result of this type of query, using the same sample file as we’ve been using, is this:
Notice in this example how we get only the authentication attempts for “user1”, BUT we also get back other lines for wrong passwords being submitted and account lockouts. That happens because those summaries contain the same keywords we are searching the summary for. It’s a bit of noise, but you could reduce that noise a bit by altering the filter to something like this:
*Summary contains "WRONG" and (not *userName == "(null)") and (*Summary contains "failure") or *Summary contains "LOCKED" and (not *userName == "(null)") and (*Summary contains "failure")
NOTE: You can also use other variations as discussed above!
This method results in output such as this:
How to update the Netlogon parser manually to v3.5
If you are using Message Analyzer 1.1, 1.2, or 1.3, but still want to take advantage of the new features introduced in the Netlogon parser v3.5, then you can follow the below 4 steps to implement the updated Netlogon parser. Please keep in mind that the Netlogon parser v3.5 is written for Message Analyzer 1.3 and beyond, so there may be bugs that were not identified in testing and are not covered in the above known issues list!
NOTE: No version of the Netlogon parser will function on any Message Analyzer version less than Message Analyzer 1.1. It is highly suggested to find a way around your deployment blocker so that you can upgrade to Message Analyzer 1.3.1 as soon as possible!
With that being said, here’s how you manually update the parser:
1. If Message Analyzer is running, please shut it down and ensure the process is no longer listed in Task Manager
2. Download the Netlogon-35-config.zip file in this blog (this zip file contains v3.5 of the Netlogon parser, as well as the “Netlogon Analysis” grid view files)
a. The files within Netlogon-35-config.zip are: Netlogon.config, Netlogon-Analysis-View.asset, and Netlogon-Analysis-View.metadata
3. Unzip Netlogon-35-config.zip to a location of your choosing
4. Copy the Netlogon.config file that you unzipped into:
a. If using Message Analyzer 1.2 or 1.3: %userprofile%\AppData\Local\Microsoft\MessageAnalyzer\OPNAndConfiguration\TextLogConfiguration\DevicesAndLogs (when prompted to overwrite the file, select the option to replace the file in the destination)
b. If using Message Analyzer 1.1: %userprofile%\AppData\Local\Microsoft\MessageAnalyzer\OPNAndConfiguration\TextLogConfiguration\AdditionalTextLogConfigurations (when prompted to overwrite the file, select the option to replace the file in the destination)
After following the above 4 steps, the Netlogon parser v3.5 should now be implemented and available for use once you reopen Message Analyzer.
How to add the new “Netlogon Analysis” grid view
As an added bonus to the new parser, an analysis grid view that contains a more refined view specific for the needs of analyzing Netlogon logs is available to download in this blog. This analysis grid contains the message number, the diagnosis (ie; diagnosis types), time elapsed, summary, trace source (the name of the source Netlogon log), and the trace source path (the path to the source Netlogon log).
Here is how you manually import the Netlogon Analysis grid view (assumes you have already imported v3.5 of the Netlogon parser and are running Message Analyzer 1.3 or 1.3.1):
1. Open Message Analyzer
2. Open a Netlogon log to begin a new session (you can drag and drop the file in or open it using the File menu or shortcuts on the start page); select the Netlogon parser and click Start
3. Above the analysis grid, click the Layout dropdown (or use the Session|Analysis Grid|Layout option)
4. Select Manage Layouts, then click Manage…
5. In the Manage View Layout screen, select Import
6. Browse to the path where you unzipped Netlogon-35-config.zip to find the file Netlogon-Analysis-View.asset, then select it and click Open, or simply double click the .asset file
7. In the Select Items to Import screen, just click the OK button
8. You should now be back in the Manage View Layout window; if you scroll down, you should see a new Netlogon category, with the Netlogon Analysis grid view listed
9. Click the OK button
10. You should now be able to select the Netlogon Analysis grid view. You can select this view from the “Layout” selection available above the analysis grid when opening a log file (1st screenshot) or from the Session à Analysis Grid à Layout menu (2ndscreenshot).
Reference links
Message Analyzer v1.3.1 download (highly recommended!)
https://www.microsoft.com/en-us/download/details.aspx?id=44226
New Features in the Netlogon Parser (v1.1.4) for Message Analyzer
Introducing the Netlogon Parser (v1.0.1) for Message Analyzer 1.1 (By: Brandon Wilson)
Troubleshooting Basics for the Netlogon Parser (v1.0.1) for Message Analyzer (By: Brandon Wilson)
Quick Reference: Troubleshooting Netlogon Error Codes (By: Brandon Wilson)
Quick Reference: Troubleshooting, Diagnosing, and Tuning MaxConcurrentApi Issues (By: Brandon Wilson)
Message Analyzer Forum
https://social.technet.microsoft.com/Forums/en-US/home?forum=messageanalyzer
Message Analyzer blog site
https://blogs.technet.com/MessageAnalyzer
Memory usage with Message Analyzer
Just to recap; please send us any suggestions or problems you identify through the comments below, the Message Analyzer forum, via email to MANetlogon@microsoft.com, or using the integrated feedback button in Message Analyzer as seen below (circled in green at the top right)!
Thanks, and talk to you folks next time!
-Brandon Wilson